Skip site navigation (1) Skip section navigation (2)

Re: psql \d option list overloaded

From: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
To: Peter Eisentraut <peter_e(at)gmx(dot)net>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Greg Stark <gsstark(at)mit(dot)edu>,pgsql-hackers(at)postgresql(dot)org
Subject: Re: psql \d option list overloaded
Date: 2004-03-31 01:06:25
Message-ID: 200403310106.i2V16Pr15273@candle.pha.pa.us (view raw or flat)
Thread:
Lists: pgsql-advocacypgsql-generalpgsql-hackers
I have added this psql backslash discussion to TODO.detail.

---------------------------------------------------------------------------

Peter Eisentraut wrote:
> 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.
> 
> 
> ---------------------------(end of broadcast)---------------------------
> TIP 4: Don't 'kill -9' the postmaster
> 

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman(at)candle(dot)pha(dot)pa(dot)us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

In response to

pgsql-hackers by date

Next:From: Philip WarnerDate: 2004-03-31 01:26:31
Subject: Re: pg_dump end comment
Previous:From: Tom LaneDate: 2004-03-30 22:58:15
Subject: Re: cvs HEAD regression

pgsql-advocacy by date

Next:From: mundoDate: 2004-03-31 01:54:48
Subject: Re: Changing mailling list server
Previous:From: Christopher BrowneDate: 2004-03-30 22:53:02
Subject: Re: Best open source db poll currently

pgsql-general by date

Next:From: Mooney, RyanDate: 2004-03-31 01:48:14
Subject: Large DB
Previous:From: Will ReeseDate: 2004-03-31 00:50:50
Subject: Problem with foreign keys and locking

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group