D. Richard Hipp wrote:
> Have you looked at the TCL bindings? The above would be
>
> db eval {select * from X where Y=$parameter} {... code here ...}
I do have a wrapper that uses a hash literal for exactly this
(although in practice I find it actually easier to read a bunch of
positional parameters on the argument list). It's actually possible
in Nasal for a function to inspect the namespace of its caller,
although I haven't bothered to implement something like that here.
> At runtime, SQLite determines the internal data representation of
> the $parameter variable, then uses bind_text, bind_blob, bind_int,
> or bind_whatever as appropriate.
I'm not quite sure I see how. This is actually exactly what I'm
doing: Nasal has two meaningful datatypes in this context: double
precision numbers and "strings", which are internally arbitrary byte
arrays. A double gets set using bind_double(), and the string using
bind_blob() (originally: now bind_text()). But if the *column* (Y, in
your example above) against which the parameter is compared has type
"text" and not "blob", that comparison always fails.
And TCL (the last I used it, which was in the mid-90's) has exactly
the same data representation as Nasal: there is no internal
distinction between a string and a byte array. It would have exactly
the same issue that I am seeing; I suspect that the only reason you
don't hit more often it is that the TCL bindings picked the opposite
convention to the one I (originally) did: they call bind_text() for
all strings instead of bind_blob().
> Well, I suppose we might have made that choice when we were defining
> the interface for SQLite version 3 - if you had brought it up then.
Is the implication then that no planning is being done for version 4? :)
This is a straw man argument you are making: I consider this issue a
bug, not an interface change, and made that case as such. You
disagree, and of course your opinion takes precedence. But to argue
that *all* such changes to query behavior are "interface changes" and
therefore unfixable seems to stretch the point of what "compatibility"
means past a reasonable breaking point. Clearly you have and will
continue to make changes that cause the results from queries to
change; you simply call them "fixes" instead of "changes". And
honestly, your implication that my asking that this issue be fixed
implies a lack of understanding about compatibility and release
management is a little insulting.
> I would rather support the thousands of applications that I know are
> already using SQLite successfully than break all those other
> application
Um, break *all* of them? Now you are simply exagerating. I find it
difficult to believe that there are thousands of applications whose
correct behavior depends on blobs being != to text when used with
bound parameters. I can't even think of even a *theoretical*
situation where this might happen. Absence of evidence is not
evidence of absence, obviously, but nonetheless, I find it more likely
that the actual number of vulnerable applications is zero. You
actually make the case yourself:
> You are the first person to complain about this in 2.5 years since
> the beginning of version 3 and I am aware of at least 2 dozen other
> language bindings that already exist and are fully functional
I strongly suspect those other languages made the same choice that the
TCL bindings did: they use bind_text() always, and never bind_blob()
except where the language or exposed API makes the distinction
explicit. And because almost no one writes schemas where comparing
blobs is required, none of these hit the issue. But for whatever
reason, I picked blob as the default; and as described, blob works
very poorly as a default, because your strings won't compare against
other strings already in the database.
I'm actually reasonably happy with this workaround from Dennis, so I'm
going to disappear from the list and not argue the case further. But
I will admit to being a little puzzled that you seem to understand the
issue yet don't find it worth fixing, even in a future verison.
Andy
-----------------------------------------------------------------------------
To unsubscribe, send email to [EMAIL PROTECTED]
-----------------------------------------------------------------------------
