Re: Views, views, views: Summary of Arguments

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: pgsql-hackers-owner(at)postgresql(dot)org [mailto:pgsql-hackers-
> owner(at)postgresql(dot)org] On Behalf Of Joshua D. Drake
> Sent: Tuesday, May 10, 2005 10:30 AM
> To: Josh Berkus
> Cc: pgsql-hackers(at)postgresql(dot)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