On 1/2/2014 11:03, Jake Colman wrote:
> 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.