[EMAIL PROTECTED] wrote:
There is good reason for this, actually.
And that pretty definitively answers the question of whether or not this
is a bug. :-)
Dennis Cote
-
To unsubscribe, send email to [EMAIL
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
Andy Ross <[EMAIL PROTECTED]> wrote:
>
> > SQLite takes the approach of always making every BLOB larger than
> > every TEXT string. That is simple and unambiguous.
>
> but it's a disaster for people like me trying to actually take
> advantage of the manifest typing feature. I have an
Actually I was talking about an application language which lets users
incorporate their own SQL and which binds to the SQL at run time rather
than being like embedded SQL.
It doesn't need to parse SQL, it just uses the existing SQL API which
provides all the necessary capability.
The
John Stanton wrote:
> The method I wrote about earlier is part of a language binding.
> I can show you the code if you are interested.
I think we must be talking about different things, then. A language
binding that allows the user to write their own SQL cannot
automatically insert cast() calls
The method I wrote about earlier is part of a language binding.
I can show you the code if you are interested.
Andy Ross wrote:
Dennis Cote wrote:
> The following log shows that sqlite does indeed distinguish
> between a text field and a blob with the same content. It also
> shows you a
Sqlite has declared types and actual types. Both can be accessed
through the API.
What I do is look at the declared type, which defines the data and then
look at the actual type to determine how to process it.
Youn can declare the type to be anything you want. A name such a GEORGE
or
Dennis Cote wrote:
> The following log shows that sqlite does indeed distinguish
> between a text field and a blob with the same content. It also
> shows you a workaround. You simply need to cast your fields to
> blobs before you compare them to a variable that is bound to a
> blob.
But I can't
D. Richard Hipp wrote:
> There is good reason for this, actually.
But I'm not sorting, nor doing a < or > comparsion. In fact none of
this has to do with comparison at all, but *identity*, which is a much
simpler test. Are you really arguing that there are situations where
a string value (in
Andy Ross wrote:
Andy Ross wrote:
Problem is, the *blob* value of "testval" does not, apparently, equal
the *text* value of "testval" in the database.
Just to head off the inevitable reply: no, this isn't an encoding issue.
The result of "pragma encoding" on the database file is UTF-8, and
Andy Ross <[EMAIL PROTECTED]> wrote:
>
> Problem is, the *blob* value of "testval" does not, apparently, equal
> the *text* value of "testval" in the database.
>
There is good reason for this, actually. TEXT values
can sort in many different orders, depending on what
collating sequence is
Andy Ross wrote:
Problem is, the *blob* value of "testval" does not, apparently, equal
the *text* value of "testval" in the database.
Just to head off the inevitable reply: no, this isn't an encoding issue.
The result of "pragma encoding" on the database file is UTF-8, and obviously
the
I'm working with the sqlite3 bindings to my "nasal" languages
(http://plausible.org/nasal, if anyone is curious) and I'm having a
problem with type conversion.
Take a look at the attached sample code. What it basically does is to
try to extract a row from a table with a bound parameter:
13 matches
Mail list logo
