On May 7, 2011, at 4:08 PM, Kemet wrote:
> * num_ is set to 51, which corresponds to "VARCHAR NULL". Indeed, I mistakenly
> forgot to add the "NOT NULL" when creating the table.
> * If escape_q is called, it returns FALSE.
It sounds like a bug to me.
> I corrected the table definition and now I get the same type 25 in both cases.
Good to know, and the correct thing in the end, but MySQL++ should defend itself against
being lied to like you did. :)
> Question remains if there is a bug in escape_q (returning false for all "nullable"
> types), or that this is caused because of a mismatch between database definition (allowing
> NULL) and SSQLS definition (not allowing NULL).
I expect that the right thing is to do something like this:
if (val.nullable && !val.is_null) {
return val.value.escape_q(); // delegate to wrapped type
}
else {
// do what we do now
}
This is very vague pseudocode. It may have to be done with an overload of escqpe_q()
instead of an 'if' statement.
You've been into that forest. Do you want to chop the bug tree down?
