Andreas, > There are only two choices: Creating a minimal subset tool, which will > rely on INFORMATION_SCHEMA (or a schema API as in ODBC) as standardized > by SQL specs, or making it specifically for every DBMS, whether using > some fancy views or not.
Thing is, INFORMATION_SCHEMA doesn't hold a lot of information that people need to know. Like permissions, comments, object owners, functions, types, etc. If adding columns and views to the Information schema ... and changing keys in a couple of places ... is OK, then we have somewhere to go. Unfortunately, PostgreSQL does not have a seat on the ANSI committee, so we're not going to get the standard changed. The standard lately belongs to Oracle and DB2 and we have to suffer under it. > Doing it seriously, it probably needs the internal DBMS object > identifiers (oid in the case of pgsql), to uniquely identify objects > even after a rename. Hiding the OIDs in schema views will reduce their > usability. Hmmm ... we argued about this. I was in favor of hiding the OIDs because OIDs are not consistent after a database reload and names are. I can see your point though; what do other people think? -- --Josh Josh Berkus Aglio Database Solutions San Francisco ---------------------------(end of broadcast)--------------------------- TIP 8: explain analyze is your friend