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@candle.pha.pa.us               |  (610)
853-3000+  If your life is a hard drive,     |  830 Blythe Avenue +  Christ can be your backup.        |  Drexel Hill,
Pennsylvania19026