RE: psql \l error

> -----Original Message-----
> From: pgsql-hackers-owner@hub.org [mailto:pgsql-hackers-owner@hub.org]On
> Behalf Of Tom Lane
> 
> 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,
> 
> >   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
\df and \dd cause an ERROR: no such function 'oidvectortypes' ...
when 7.0 psql talks to pre-7.0 servers. I've noticed the fact but I
didn't know what should be done.
What kind of backward compatibity is required for psql etc..? 
Are there any documentations about it ?  Of cource it's preferable
that client application/libraries aren't tied to a specific version of
server application.

Regards.

Hiroshi Inoue
Inoue@tpf.co.jp