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
|
Список | 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 по дате отправления: