Re: psql \d option list overloaded - Mailing list pgsql-hackers

From Peter Eisentraut
Subject Re: psql \d option list overloaded
Date
Msg-id 200401121848.43765.peter_e@gmx.net
Whole thread Raw
In response to Re: psql \d option list overloaded  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: psql \d option list overloaded  (Bruce Momjian <pgman@candle.pha.pa.us>)
List pgsql-hackers
Tom Lane wrote:
> But this interacts with point 3 (psql breaks on every new backend
> version).  It's not desirable to have every GUI and large custom
> program implementing its own set of metadata inquiry commands: they
> all have to go through the same update pain as psql.  Perhaps if
> people start to rely on information_schema for those things, life
> will get better, but I'm unconvinced that will happen.  psql itself
> certainly hasn't moved in that direction.

IIRC, the two killers in psql compatibility have been outer joins and 
schemas.  I don't see how we could have avoided that, except with 
highly specialized and static (parameter-less) commands.  There have 
been additional minor issues, but I suppose we could have avoided those 
if we had cared to do so at all.

Several people have in the past proposed to keep psql backward 
compatible, even if only by means of

if (version =x) {  ...
}
else if (version = y) {  ...
}

(which would be fine by me), but apparently no one has felt pressed 
enough yet.



pgsql-hackers by date:

Previous
From: Jan Wieck
Date:
Subject: Re: [ADMIN] IEEE 754
Next
From: Sai Hertz And Control Systems
Date:
Subject: Re: [ADMIN] IEEE 754