Re: Adding column comment to information_schema.columns - Mailing list pgsql-hackers

From Hannu Krosing
Subject Re: Adding column comment to information_schema.columns
Date
Msg-id 1088800866.16052.7.camel@fuji.krosing.net
Whole thread Raw
In response to Re: Adding column comment to information_schema.columns  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On R, 2004-07-02 at 20:04, Tom Lane wrote:
> Bruno Wolff III <bruno@wolff.to> writes:
> >   Christopher Kings-Lynne <chriskl@familyhealth.com.au> wrote:
> >> Why are they useful???? If you want PG specific stuff then use the PG 
> >> specific catalogs!!!
> 
> > The information schema could be used to provide a more stable interface.
> > The pg catalog changes from release to release and it would be nice to
> > be able to write code which is more future proof.
> 
> Isn't this argument self-contradictory?  The reason information_schema
> is stable is that it is standard.  If we start hacking it up to add
> implementation-specific stuff, then you lose that stability.  You'll
> need to consider the PG version when deciding what queries you can
> issue, and there will undoubtedly be scenarios where we have to change
> or remove columns that we've added to information_schema.

Sure. But there are also many that change in pg_* tables but still can
be kept the same in information schema. The column numbering issues that
came up when adding "delete column" are one example.

Of course, just adding "everything" is a bad idea, but surely there are
some things that are not in standard information schema but could be
added as *_ extensions.

I think that extending information schema in a standard-stipulated way
is a better idea than having a separate pg_information_schema for schema
future-proofing use.

-------------------
Hannu



pgsql-hackers by date:

Previous
From: Thomas Swan
Date:
Subject: Re: Nested Transactions, Abort All
Next
From: Robert Treat
Date:
Subject: Re: working on support triggers on columns