On 18/09/2019 15:24, xxxxxx@ancell-ent.com wrote:
>> In fact, I suspect the values of the alist should probably be a list of
>> values obtained from bindings exported from the DBI or DBD modules, or
>> the results of calling procedures exported from same:
>
> My ideal is that the DBI level won't be parsing any part of queries or
> other statements, it should be query language agnostic, the thin wrapper
> you mention below, and let the levels above and below deal with this.

Maaaaybe...

>> (mysql:result-string-encoding 'latin-1)   (interpret strings received
>> from MySQL as being encoded in latin-1 rather than the database default)
>>
>> etc?
>
> Yes, except would the last example be MySQL specific?

It might be useful for some other databases that also have might have
different encodings for different returned strings, which postgresql and
sqlite don't as far as I can tell... Whether we have
mysql:result-string-encoding and
some-other-archaic-database:result-string-encoding that do the same
thing in two different drivers, or whether we identify this as a common
case and define a dbi:result-string-encoding that is an error on
database that handle the encoding themselves, is open for debate!

> And SQLite for
> example doesn't have a timestamp datatype, or "storage type", only NULL,
> INTEGER, REAL (floating point), TEXT, and BLOB.  Time and dates are done
> by convention, with SQLite providing encoding and decoding functions.

Sure, but SQL-92 has a TIMESTAMP WITH TIME ZONE so it might be said that
"the SQL type system" has such a type (which most database backends
support), and it'd be nice to be able to use it directly most of the
time... By which I mean, as a "timestamp with time zone" thing exists in
SQL there should be a defined Scheme type for it that will work
correctly with any database that has a "timestamp with time zone" value
in it.

Now - that type, and the expectation that it'll map back and forth,
might be considered to be part of a "SQL-92 package" of types and
facilities that apply to all such DBs. A sqlite DBD might *emulate* that
for convenience (storing timestamp-with-timezone values in some format
of its own by default, or allowing for sqlite:... DBD-specific things to
specify some other storage format for compatability with existing sqlite
DBs), while an unashamedly nowhere-near-SQL database (would MongoDB fit
into this model?) wouldn't even try, I presume.

>> Whereas the mysql DBD can just scan the list for string encoding
>> directives at the point where it's creating the scheme string, then
>> pass any directives it's not interpreted itself off to a DBI "standard
>> sql to scheme mappings" procedure (which will complain if there are
>> any directives it can't understand, if somebody accidentally used a
>> sqlite directive in a mysql query...)
>
> Indeed, except I'm not sure I'd place the "standard sql to scheme
> mappings" procedures at the DBI level, e.g. it shouldn't even know SQL.

In a "SQL tools" library, then, shared between all DBDs that are (or
approximate) ANSI SQL?

>
> - Harold
>

--
Alaric Snell-Pym   (M7KIT)
http://www.snell-pym.org.uk/alaric/