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

From Stephan Szabo
Subject Re: Adding column comment to information_schema.columns
Date
Msg-id 20040701095654.X31438@megazone.bigpanda.com
Whole thread Raw
In response to Re: Adding column comment to information_schema.columns  (jearl@bullysports.com)
List pgsql-hackers
On Thu, 1 Jul 2004 jearl@bullysports.com wrote:

> Andreas Pflug <pgadmin@pse-consulting.de> writes:
>
> > Justin Clift wrote:
> >
> >> Tom Lane wrote:
> >>
> >>>
> >>> This question has been touched on before, but I guess it's time to
> >>> face it fair and square: is it reasonable for an SQL
> >>> implementation to add implementation-specific columns to an
> >>> information_schema view?  One could certainly argue that the
> >>> entire point of information_schema is to be *standard*, not more,
> >>> not less.  OTOH I do not know if adding an extra column is likely
> >>> to break anyone's application.  Comments?
> >>
> >>
> >> Well, I suppose it reduces application portability if anyone starts
> >> relying on it.
> >
> >
> > We're advertising to do pure ANSI, so we'd mislead people if we
> > supplied non-standard columns.
>
> Yes, but if folks wanted to stick to the standard PostgreSQL would
> still work.  The only difference is that people who aren't concerned

That might not be true.  It is possible to write queries that might work
on a database without extra columns and would fail or act differently with
extra columns depending on things like the names of the added columns
(possibly altering natural join), the positions of the column (possibly
altering sql92 order by ordinal position behavior) and the existance of
the column itself (possibly altering queries that use select * on one
branch of a union/intersect/except query for example).


pgsql-hackers by date:

Previous
From: Dennis Bjorklund
Date:
Subject: Re: Adding column comment to information_schema.columns
Next
From: Manfred Spraul
Date:
Subject: Re: xeon processors