Tyler MacDonald wrote:
Tim Bunce <[EMAIL PROTECTED]> wrote:
PostgreSQL is non-standard (and inconvenient) in this respect.
I chatted with Mischa (my work's resident DB guru) about this, and
according to him, the error behaviour when you attempt to SELECT from a
table that does not exist is "undetermined" in the SQL standard, so it
really is the individual DBMS' choice. I think that's actually worse; all of
these DBMs are behaving completely differently but still "correctly" on such
a basic SQL operation due to a lack of standard!
Hope you don't mind my chirping up ...
Specifying behaviour down to the detail level of executing app errors
would be enough to keep a bunch of DBMS vendors from EVER adopting
a standard. It's not like Perl. It's way more like COBOL. Hard enough to agree
on what to do when the app follows the rules.
The ODBC solution was to allow any DB to express its abilities in crazy detail,
through SQLGetInfo. What kinds of joins it supported, what kinds of transaction,
and then let the app do or not do what it had to ... Does DBI have something
like that?
There isn't, as far as I know, except to accept the 'lowest common
denominator'. In this case that means forcing a rollback if any
statement fails.
How about having DBI implement a consistent nested-transaction interface that
compliant DBMS's can support?
--
Some people think the glass is half-full.
Some people think the glass is half-empty.
Engineers think, "This glass is twice as big as it needs to be."
