On Tuesday 2012-05-15 10:16 (-0700), M.-A. Lemburg <m...@egenix.com> wrote:
What you're describing sounds a lot like the catalog methods in
the ODBC standard.
Those are typically implemented by either
having the ODBC drivers implement a set of queries that generate
result sets in a predefined format, or by adding views to the
database backend which implement them. Sometimes, both methods
are used.
The application can then call the catalog methods with a
set of parameters and the database will run the queries to
build the result set with meta data.
Even though most databases provide the needed information,
I'm not sure whether we should ask database module authors
to implement similar catalog methods. The reason is that
for some of them, the required information may not be
readily available in the database, or may require installing
views to allow users without full permissions to retrieve
the data from the system tables.
We could standardize those methods as optional add-ons to
the DB-API specification, though, so that those modules
which do want to implement them at least all use the
same methods, parameters and result set layouts.
If there is interest in this, I'd suggest to follow the
ODBC standard for this and use method names derived from
the ODBC API names. mxODBC implements these and also
documents the result set layouts:
http://www.egenix.com/products/python/mxODBC/doc/#_Toc269754615
I agree with this approach, it should be optional. The original Jython
JDBC driver implemented meta data lookup functions with a similar API
(JDBC and ODBC are very similar). See
http://www.jython.org/archive/21/docs/zxjdbc.html for more details.
if you need this today, I'd recommend Vernon's idea, implement a
separate package (possibly based on some code from
http://halfcooked.com/code/gerald/schema_api.html )
Chris
_______________________________________________
DB-SIG maillist - DB-SIG@python.org
http://mail.python.org/mailman/listinfo/db-sig
