Re: psql \l error
Tom Lane <tgl@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Peter Eisentraut <peter_e@gmx.net>
Cc: SAKAIDA <sakaida@psn.co.jp>, pgsql-hackers@postgresql.org
Date: 2000-05-02T15:39:07Z
Lists: 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