Dear folks,
Carsten Haese wrote:
On Thu, 2006-11-16 at 13:18 -0500, Art Protin wrote:
Dear folks,
In earlier messages, I noted that the Specification (v2.0) does
not adequately express that the "operation" argument is SQL (although
the coverage of the API in "PYHON in a Nutshell is hardly ambiguous at
all). Now I am wondering about the distinction between SQL DQL (Data
Query Language) and SQL DDL (Data Definition Language). Is there
intended to be any support for DDL in this API? (I am not sure of if or
how I could put that support into the implementation I am working on,
but I do not need to think about it much if none is intended.)
I'm afraid you'll have to think about it, unless the database engine
you're interfacing with doesn't support any kind of DDL, which I find
unlikely. The (unwritten) intent of the specification is that an
implementation should support any operation that is supported by the
underlying DBMS. For SQL engines that means DQL, DML, DDL, and DCL.
Good. This is more than enough leeway.
Maybe it would help if you explained why you think you need to make an
exception for DDL.
I am implementing support for a DBMS that is not an SQL engine but does
have a translator of SQL into native queries. The DQL & DML are handled
together through one interface while the DDL is handled through a
different one (and I have not found support for DCL).
So, as I understand it now, I need to make a "good faith effort" and as
long as my users are happy I am not lying when I claim the interface
largely complies with the spec. Or stated slightly different, the
failure to support DDL (if it proves too difficult) will simply need to
be listed in my documentation as another point of non-conformance.
Whenever the specification is revised, I would recommend that this
intent be given some visibility.
-Carsten
_______________________________________________
DB-SIG maillist - DB-SIG@python.org
http://mail.python.org/mailman/listinfo/db-sig
