List:MySQL++« Previous MessageNext Message »
From:Jake Colman Date:January 2 2014 6:03pm
Subject:Re: Unmapped MYSQL_TYPE enums
View as plain text  
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?

Thanks.

*Jake Colman*

*Director, Development *| Billtrust

Tel: 609.235.0792 | email: jcolman@stripped | Web: www.billtrust.com

Follow us: Twitter <http://www.twitter.com/billtrust>|
Facebook<http://www.facebook.com/Billtrust.CompleteBilling>|
LinkedIn <http://www.linkedin.com/company/99112> |
Blog<http://blog.billtrust.com/>


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

> On 1/2/2014 10:04, Jake Colman wrote:
>
>>
>> MYSQL_TYPE_YEAR
>> MYSQL_TYPE_NEWDATE
>> MYSQL_TYPE_BIT
>> MYSQL_TYPE_VARCHAR
>> MYSQL_TYPE_GEOMETRY
>>
>
> 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
>
>

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