Suggestion: Use INFORMATION_SCHEMA for everything that INFORMATION_SCHEMA covers. That way, there will not be needless duplications.
Create new tables with foreign keys to the INFORMATION_SCHEMA for everything else. Alternative suggestion: Create any sort of magic, pg-specific schema you want, and create views that map the stuff back to the INFORMATION_SCHEMA to fill INFORMATION_SCHEMA out completely. Both methods are equally good to me. What would be painful (in my view) is if the new "custom" schema has INFORMATION_SCHEMA data in it, and the INFORMATION_SCHEMA does not contain that needed information (IOW: INFORMATION_SCHEMA lags behind because the PG specific schema gets lots of work and the INFORMATION_SCHEMA gets secondary attention). As long as I get my INFORMATION_SCHEMA views, and as long as they are fully populated, I would not care at all if there were additional information somewhere else. > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:pgsql-hackers- > [EMAIL PROTECTED] On Behalf Of Joshua D. Drake > Sent: Tuesday, May 10, 2005 10:30 AM > To: Josh Berkus > Cc: pgsql-hackers@postgresql.org > Subject: Re: [HACKERS] Views, views, views: Summary of Arguments > > > > > ... thus, as I see it, the *primary* question is in fact argument (2). > That > > is, is information_schema sufficient, and if not, can it be extended > without > > breaking SQL standards? Argument (1) did not seem to have a lot of > evidence > > on the "con" side, and the strongest argument against (3) is that we > should > > use information_schema. > > (2) The information_schema is good but not sufficient. It either needs > more info as suggested by this thread or we need an extended version for > Pg specifically. > > (1) I can't see anyone in their right mind on the user space / support > of users side arguing against the need for more information about > PostgreSQL and the way it interacts. > > (3) If we can use the information_schema let's do so. However it should > not be a stopping block. > > Sincerely, > > Joshua D. Drake > Command Prompt. Inc. > > > -- > Your PostgreSQL solutions company - Command Prompt, Inc. 1.800.492.2240 > PostgreSQL Replication, Consulting, Custom Programming, 24x7 support > Managed Services, Shared and Dedication Hosting > Co-Authors: plPHP, plPerlNG - http://www.commandprompt.com/ > > ---------------------------(end of broadcast)--------------------------- > TIP 4: Don't 'kill -9' the postmaster ---------------------------(end of broadcast)--------------------------- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq