Re: psql \l error - Mailing list pgsql-hackers
From | SAKAIDA |
---|---|
Subject | Re: psql \l error |
Date | |
Msg-id | 390E7C973A2.E183SAKAIDA@smtp.psn.ne.jp Whole thread Raw |
In response to | Re: psql \l error (Tom Lane <tgl@sss.pgh.pa.us>) |
Responses |
Re: psql \l error
(Bruce Momjian <pgman@candle.pha.pa.us>)
|
List | pgsql-hackers |
Tom Lane <tgl@sss.pgh.pa.us> wrote: > SAKAIDA <sakaida@psn.co.jp> writes: > > A_server : configure (in USA) > > B_server : configure --enable--multibyte (in Japan) > > > By using the B_server's psql, > > > > prompt> psql -h A_server > > ERROR: Multibyte support must be enable to use this function > (snip) > > 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. > > postgres=# \l > > ERROR: No such function 'pg_encoding_to_char' with the > > specified attributes > > Hmm. This is happening because 7.0 psql tries to display the encoding > of each database if psql was compiled with MULTIBYTE. > > Here you are evidently talking to a pre-7.0 server (both because > a 7.0 server should have that function, even if the function > refuses to work ;-)) and because a 7.0 server does not spell the > 'No such function' error message quite that way. Sorry, I have used a 6.5.3 as the A_server certainly. In the case of a 7.0, prompt> export PGCLIENTENCODING='SQL_ASCII' prompt> psql -h A_server postgres=# \l ERROR: Multibyte support must be enableto use this function > (snip) > 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. -- Regards, SAKAIDA Masaaki -- Osaka, Japan
pgsql-hackers by date: