> The "datatype" that comes closest to being a suitable native byte
array
> these days is Stdio.Buffer.
Is this true? If the binding were to interpret any Buffer object as
binary data, would that cause surprise? My reading suggests that it is a
grey area and I'd rather solve the problem unambiguously if it's
possible.
> I presume you mean SQLite with typed queries here?
I'm not sure what a typed query is; this has to do with using binding
parameters and the way the pike glue to SQLite binds a given parameter.
> doing this and hasn???t run into this problem?), as any 8-bit
strings
> that weren???t binary data would be stored as blobs, even if they
were
> in a text typed field. These records would need to be re-stored
with
> the proper text type, which could be done with a query to update
the
> table. My sense is that this is the proper thing to do, as blob
fields
> should be reserved for data that???s actually binary data (as
opposed
> to text).
> - The contortions you describe to get the queries right with the
current
> behaviour would indicate that anyone who would have tried to do
the same
> would likely have ended up complaining here while trying to get it
right.
I have a hard time imagining that anyone has tried it. Not only does it
cause all kinds of complications within pike, it also means that queries
executed directly against the sqlite command would fail in similar ways,
as there could be mixed types of data within a given column and writing
some string as a blob literal means converting it to hex data first,
which isn't something many people can do on the fly.
> - In general I've noticed that very few, if any, people are
actually using
> *typed* queries from Sql.Sql.
> So that would suggest that your change would be beneficial, and
would
> (for safety) require a bit of compat code to get it right for
anyone
> unfortunate enough to rely on older behaviour.
I would argue the opposite: the existing behavior is so broken that
trying to come up with compat for it would just make existing code more
brittle because the effect of the current code is to effectively corrupt
the data in a column.
Example:
a column of type text may have individual elements that are text or blob
(or number even) values depending on whether the data was inserted using
a text literal 'some text', a blob literal X'14EC24', a binding
parameter from pike that happened to be a wide string (stored as text)
or a narrow string (stored as binary). So any query run against such a
column would likely return incorrect results unless the values and the
query values were always cast to one or the other.
I can't think of a scenario where this is desirable. Even if you ignore
applications written for ASCII code only, I imagine there are lots of
narrow values in languages that also have wide characters.
My proposal would be to fix this so that all strings are stored as text
and that all values of some other object type (Stdio.Buffer or
preferably some Sql datatype wrapper for bytestrings) are stored as
blobs. A reasonable workaround for anyone crazy enough to use the
existing broken functionality can just wrap their narrow strings with
the object mentioned above and have that value bound as a blob... the
perfect use of a release note.
I'd also argue that this ought to be fixed in 8.0 as well... the
behavior is so bad that I honestly can't imagine anyone has used it
successfully.
Bill
