Re: psql \l error

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Peter Eisentraut <peter_e(at)gmx(dot)net>
Cc: SAKAIDA <sakaida(at)psn(dot)co(dot)jp>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: psql \l error
Date: 2000-05-02 15:39:07
Message-ID: 3958.957281947@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Peter Eisentraut <e99re41(at)DoCS(dot)UU(dot)SE> writes:
>> I think there are some other small incompatibilities between 7.0 psql
>> and pre-7.0 servers anyway, so eliminating this one by dumbing down \l
>> is probably not the way to proceed.

> The oidvector thing is essentially a show stopper for this.

Yes, that was the other problem I was trying to recall.

Perhaps someday we might consider offering views on the system tables
that are defined in a way that keeps old applications happy. However,
for something like the oidvector change there's just no way: an old app
that is looking at those fields is just not going to do the right thing
for functions or indexes with more than 8 arguments/columns, no matter
how we try to mask the change. I think in these cases we are better off
to do what we did, ie, change the type name or whatever, so that those
old apps break in a fairly obvious way rather than failing subtly or
infrequently.

Looking at less generic answers, I suppose that psql could try to use
a 7.0-compatible query and fall back to a 6.5-compatible query if that
fails. I imagine Peter will class this answer as "too ugly to live" ;-).
Certainly I don't have any interest in doing it, either, but maybe there
is someone out there who really needs a single psql to offer \df ability
with both generations of servers. If so, that's the way to proceed.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Adam Haberlach 2000-05-02 15:45:11 Re: Patch submission
Previous Message Tom Lane 2000-05-02 15:19:51 Re: When malloc returns zero ...