Re: psql \l error

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: psql \l error
Дата
Msg-id 3958.957281947@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: psql \l error  (Peter Eisentraut <e99re41@DoCS.UU.SE>)
Ответы Re: psql \l error  (Peter Eisentraut <peter_e@gmx.net>)
Список pgsql-hackers
Peter Eisentraut <e99re41@DoCS.UU.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


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Adam Haberlach
Дата:
Сообщение: Re: Patch submission
Следующее
От: Tom Lane
Дата:
Сообщение: Re: shmem_seq may be a bad idea