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?
*Director, Development *| Billtrust
Tel: 609.235.0792 | email: jcolman@stripped | Web: www.billtrust.com
Follow us: Twitter <http://www.twitter.com/billtrust>|
LinkedIn <http://www.linkedin.com/company/99112> |
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: http://lists.mysql.com/plusplus
> To unsubscribe: http://lists.mysql.com/plusplus