SQLwaterheadretard3 (Was: Is it just me, or is Sqlite3 goofy?)
mikeowens at gmail.com
Tue Sep 12 15:42:41 CEST 2006
On 12 Sep 2006 00:15:41 -0700, sjdevnull at yahoo.com <sjdevnull at yahoo.com> wrote:
> Just to be fair...
> You do hear many people claiming exactly that, and the primary
> complaint is often exactly the same one that's being levelled against
> sqlite here (it's incredibly lax with types and does sometimes
> mystifying conversions rather than pointing out programmer errors--and
> yes that's intentionally loaded language that I don't necessarily agree
> with, it's a common argument though.).
Yet not a single conversion is undocumented in SQLite, nor is its type
affinity. It works exactly as advertised. And MySQL's chief type
conversion gotchas -- primarily dates/times I think -- were also
clearly addressed in the documentation, and where changed in later
versions of MySQL. Then there is, as I think another person pointed
out on this thread, Oracle's silent conversion of empty strings to
NULLs in VARCHAR fields -- talk about mystifying. What about Oracle's
native date format, which also has no relation to the standard? I have
little experience with Oracle, but from what I can tell, to get it to
display dates in standard (ISO) format, you have to set the
NLS_DATE_FORMAT at the session or database level, which requires
either additional SQL commands, or administrative intervention. More
so-called non-SQL compliant behavior, although hardly a surprise (or
even a problem) to someone who is experienced with Oracle.
The bottom line: to use *any* database effectively, big or small, one
has to read its documentation, not the SQL standard.
More information about the Python-list