| From: | Josh Berkus <josh(at)agliodbs(dot)com> | 
|---|---|
| To: | Andreas Pflug <pgadmin(at)pse-consulting(dot)de> | 
| Cc: | PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> | 
| Subject: | Re: Views, views, views! (long) | 
| Date: | 2005-05-05 17:48:55 | 
| Message-ID: | 200505051048.55708.josh@agliodbs.com | 
| Views: | Whole Thread | Raw Message | Download mbox | Resend email | 
| Thread: | |
| Lists: | pgsql-hackers | 
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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Alvaro Herrera | 2005-05-05 17:49:36 | Re: A real puzzler: ANY way to recover? | 
| Previous Message | Josh Berkus | 2005-05-05 17:45:24 | Re: [pgsql-advocacy] Increased company involvement |