On Tue, May 31, 2011 at 8:31 PM, Roger Binns <rog...@rogerbinns.com> wrote:
> -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 05/31/2011 05:00 AM, Richard Hipp wrote: > > Any parameter that is optimized out > > becomes an anonymous parameter for which sqlite3_bind_parameter_name > returns > > NULL. > > This is extremely annoying behaviour, unexpected and non-obvious. > It's been that way for 6 years, and nobody has noticed until Patrick complained earlier today. > > The developer who writes the C code interface to SQLite is not necessarily > the same one who writes the queries. There is no way for the developer of > the C interface to detect the difference between an erroneous query and one > where SQLite is presenting post-optimization results. > > As an example this behaviour breaks both independently developed Python > interfaces to SQLite. They both expect to be provided bindings either by > name or by position, but not both at the same time. The detection is done > by expecting sqlite3_bind_parameter_name to either return all names or all > NULL and exceptions are generated if that is not the case. > > Please keep the name around and ignore the binding. The way sqlite3_bind_parameter_name() works is that it scans through the prepared statement's bytecode looking for parameters that need filling in. So the reason that sqlite3_bind_parameter_name() returns NULL when a parameter gets optimized out is that there is no parameter for it to locate in the bytecode. Hence, the fix is a little trickier than it might seem at first glance. One approach, I suppose, would be to generate dead code for any unused parameters. Another approach would be to disable expression optimizations that might optimize out a parameter. Neither approach seems very appealing. Both approaches add code, making the library slightly larger and more complicated, and increasing the number of tests needed for coverage. Both approaches needlessly drain some small but finite amount of energy out of your cellphone battery. So, in summary, the "problem" has been with us for 6 years and nobody has cared. And "fixing" it reduces the battery life on your cellphone by some small amount. Are you *sure* this is something that needs to change? > Or failing that please > show how someone writing C interface code can detect the difference between > the SQL query author mixing named and unnamed parameters (in error) versus > only using one of those and "optimizations" happening? > > Roger > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.11 (GNU/Linux) > > iEYEARECAAYFAk3liFUACgkQmOOfHg372QQ0AgCgu8vE+DBOglYL5oPsmDqXHgy1 > 8CIAn1MnvIfWNGv1+ffJyYMjO75Azp9o > =jFIz > -----END PGP SIGNATURE----- > _______________________________________________ > sqlite-users mailing list > sqlite-users@sqlite.org > http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users > -- D. Richard Hipp d...@sqlite.org _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
