well I already have a few of the information_schema tables in a
package called sqlalchemy.databases.information_schema, and youre
free to embellish that package.....but its only going to be good for
postgres and somewhat for mysql5 for the forseeable future...Oracle
seems to always lag behind sql standards and I dont know much about
any plans for support from the other databases you hear about
(firebird, maxdb, sybase, sqlite, SQL server...)
it might be more useful, considering the sketchy status of
information_schema (plus i think its layout is pretty esoteric for
most uses), for each database to export a view of some kind, maybe
just two or three selectables, that just provides basic table,
column, and constraint information. even if every DB supported
information_schema, it still could be preferable...with
information_schema, maybe im missing the point or something, but I
literally have to decide among (at least) four different tables to
figure out how to inspect a foreign key constraint (key_column_usage,
constraint_column_usage, referential_constraints, table_constraints,
constraint_table_usage...why so many ambiguous tables ??? and with
mysql, theyre not even the same tables, and I *still* cant detect
foreign keys). its got all the appearances of one of those
"standards" every vendor either ignores or never implements correctly.
On Jan 10, 2006, at 10:06 PM, [EMAIL PROTECTED] wrote:
On Jan 10, 2006, at 6:38 PM, Michael Bayer wrote:
well if you are referring to the "information schema" that
postgres uses, only postgres has that specific schema represented
within it (and its also quite complicated). Mysql seems to
support a slightly different version of it and also one that
doenst seem to work completely. other databases that I know of
have no notion of that particular style of information schema
(oracle for example has the data dictionary which is completely
different).
sorry, yes; i primarily use postgres and my
impressions are probably skewed from that.
nevertheless, my impression had been (and
seems to be confirmed based on googling),
that the information_schema is part of sql92,
and hence for what it's worth "standard".
by "information schema" you mean just some genericized way to get
at major schema objects ? or specifically the one presented in
postgres' set of tables ? if you are just looking for a more open-
ended way to access the listings of tables, columns, indexes,
etc., other than constructing a Table or Index, thats not
necessarily a bad thing. I can help with API design on this if
you have a proposal in mind. Im also really hoping someone wants
to chip in on the existing schema reflection if not this new idea
as well, currently table reflection is only functional for sqlite,
postgres, and mysql 5.
my intent was simply to create a Table
for the tables in information_schema -
i had presumed that filling the details
in could happen incrementally based on
(say) the lower-common-denominator between
http://www.postgresql.org/docs/8.1/static/information-schema.html
and
http://dev.mysql.com/doc/refman/5.0/en/information-schema.html
i'm likely missing compatibility issues,
since the only other db that i use is
sqlite and i'm using that less and less
these days.
fwiw, my main interest is in allowing
atomic creation of (gensym)ed tables -
i could do this by iteratively catching
"exists" exceptions, but i was hoping
to pre-filter.
thx,d
-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
_______________________________________________
Sqlalchemy-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/sqlalchemy-users
