On Thu, 1 Jul 2004 [EMAIL PROTECTED] wrote:
> Andreas Pflug <[EMAIL PROTECTED]> 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).
---------------------------(end of broadcast)---------------------------
TIP 9: the planner will ignore your desire to choose an index scan if your
joining column's datatypes do not match
