List:MySQL++« Previous MessageNext Message »
From:Jake Colman Date:January 2 2014 6:03pm
Subject:Re: Unmapped MYSQL_TYPE enums
View as plain text  

Fair enough and that makes sense.  You only support those types that are
needed by the library.

But how does that work for MYSQL_TYPE_NEWDATE, for example?  Newer servers
define date fields using  MYSQL_TYPE_NEWDATE instead of the obsolete
 MYSQL_TYPE_DATE.  Why doesn't that imply that mysqlppl has to support that
type?  Or am I misunderstanding how you're using these types?


*Jake Colman*

*Director, Development *| Billtrust

Tel: 609.235.0792 | email: jcolman@stripped | Web:

Follow us: Twitter <>|
LinkedIn <> |

On Thu, Jan 2, 2014 at 12:22 PM, Warren Young <mysqlpp@stripped> wrote:

> On 1/2/2014 10:04, Jake Colman wrote:
> That part of MySQL++ is not really a "public" API.  It exists for
> MySQL++'s own needs.  Since MySQL++ doesn't have specific support for these
> types -- there is no MySQL++ bit type, or a "geometry" type, or... -- it
> doesn't reference those enum values.
> MySQL++ doesn't provide 100% coverage of the entire MySQL C API, it never
> claimed to, and there isn't even a stated goal that this gap is to be
> driven to 0.  MySQL++ only provides facilities that someone with drive and
> ability wrote.
> If this gap bothers you, patches are always thoughtfully considered.
> --
> MySQL++ Mailing List
> For list archives:
> To unsubscribe:

Unmapped MYSQL_TYPE enumsJake Colman2 Jan
  • Re: Unmapped MYSQL_TYPE enumsWarren Young2 Jan
    • Re: Unmapped MYSQL_TYPE enumsJake Colman2 Jan
      • Re: Unmapped MYSQL_TYPE enumsWarren Young2 Jan