> > 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
