From: Warren Young
Date: May 7 2011 10:24pm
Subject: Re: SSQLS with BINARY column is sometimes not escaped
List-Archive: http://lists.mysql.com/plusplus/9344
Message-Id: <6B0CE467-9F7C-4650-A4FC-99E656125DC5@etr-usa.com>
MIME-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable

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?=