6 messages in com.mysql.lists.plusplusRe: TypeInfo Lookup failure| From | Sent On | Attachments |
|---|---|---|
| Steven Van Ingelgem | 13 Apr 2008 12:54 | |
| Warren Young | 13 Apr 2008 13:41 | |
| Steven Van Ingelgem | 13 Apr 2008 14:13 | |
| Warren Young | 21 Apr 2008 07:38 | |
| Steven Van Ingelgem | 21 Apr 2008 11:18 | |
| Warren Young | 21 Apr 2008 12:18 |
| Subject: | Re: TypeInfo Lookup failure |
|---|---|
| From: | Steven Van Ingelgem (ste...@vaningelgem.be) |
| Date: | 04/21/2008 11:18:07 AM |
| List: | com.mysql.lists.plusplus |
I am/was using it to store bigints in it. At work I was working with 10 decimals... Which is just too long for an unsigned int. Though they could fit in an unsigned long it... Which I did... But a long long would come more close to the meaning of a bigint.
For my case it's solved ;-).
Greetz
On 21/04/2008, Warren Young <mysq...@etr-usa.com> wrote:
Steven Van Ingelgem wrote:
That was for v3.0.1 & v3.0.0...
Oh. In that case, try switching to one of the new types defined in lib/sql_types.h. my_ulonglong is a MySQL specific type, used for its own C API, not really something meant to map to the SQL type system. Its meaning changes depending on the platform, not a desirable behavior, which is probably why I removed support for it.
If you still feel MySQL++ needs to support something compatible with my_ulonglong, I'll need a SQL-oriented justification. The current data type handling system is pretty hairy -- less so in 3.x, but still hairy -- and adding support to it for every arbitrary data type has to be done by hand, increasing the code's hirsuteness. To justify that, I need a case where useful SQL can't be done without this type.
-- MySQL++ Mailing List For list archives: http://lists.mysql.com/plusplus To unsubscribe: http://lists.mysql.com/plusplus?unsub=ste...@vaningelgem.be