Re: psql \l error

> > Seems like it might be a good idea if the non-MULTIBYTE stub versions of
> > pg_encoding_to_char() and friends were to return default values (eg,
> > "SQL_ASCII") instead of erroring out. A MULTIBYTE version of psql
> > really ought to be able to work with a non-MULTIBYTE server.
>
> I think so, too.

Agreed.

> > This one is a little nastier. The only solution I could see that would
> > guarantee backwards compatibility is for psql not to try to display the
> > database encoding; that doesn't seem like a win. 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.
> >
> > So, I'd suggest fixing the first issue (so that 7.0 MULTIBYTE psql works
> > with non-MULTIBYTE 7.0 server) but not trying to do anything about
> > MULTIBYTE psql with a pre-7.0 server. Comments?
>
> I consider that MULTIBYTE 7.0-psql must be able to access a
> pre-7.0 server. I don't think that it is so difficult to realize
> it between 6.5.x and 7.0.
>
> Problems except for \l are \df/\dd which Hiroshi Inoue already
> pointed out.

We have allowed old psql's to talk to new servers, but not new psql's
talking to older servers. For 7.0, I think they will have to match.
There really isn't a way to fix the new oidvector changes for older
releases, and I don't think it is worth it, personally.

--
Bruce Momjian | http://www.op.net/~candle
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026