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
This is evidently happening because psql's initial inquiry about the
database encoding fails.
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.
> 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.
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?
regards, tom lane
