List:MySQL++« Previous MessageNext Message »
From:Warren Young Date:January 2 2014 7:24pm
Subject:Re: Unmapped MYSQL_TYPE enums
View as plain text  
On 1/2/2014 11:03, Jake Colman wrote:
> Warren,
>
> 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?

MySQL++ dates from the days of MySQL 3.x, and no one has bothered to 
change MySQL++ to use this newer MySQL C API feature since that original 
code went in.

 From [this post](http://lists.mysql.com/internals/37677), I don't see 
that the difference really matters to MySQL++ anyway.  MySQL++ mainly 
deals with SQL values in text form, not raw binary form.  (BLOB being 
the obvious exception.)

If you know a reason why we should support this API feature anyway, I'll 
want a) a patch; b) a justification; and c) an explanation of how it 
affects the library's backwards compatibility.
Thread
Unmapped MYSQL_TYPE enumsJake Colman2 Jan 2014
  • Re: Unmapped MYSQL_TYPE enumsWarren Young2 Jan 2014
    • Re: Unmapped MYSQL_TYPE enumsJake Colman2 Jan 2014
      • Re: Unmapped MYSQL_TYPE enumsWarren Young2 Jan 2014