On 2000-02-19, Tatsuo Ishii mentioned:
> I have added new backslash command \eset and \eshow to psql.
> (only enabled if --enable-multibyte specified)
> Modified files are help.c and command.c.
Next time, make sure to update the documentation as well.
> o \eset <encoding>
>
> change the client encoding to <encoding>.
> o \eshow
>
> show the client encoding.
I took the liberty to change that to \encoding <x> sets the encoding and
\encoding without arguments shows it. Also you can do \echo :ENCODING.
That fits in better with the rest.
I have a question for you, though. Right now, when I have a non-multibyte
backend and a multibyte psql I get this when I start up psql:
psql: ERROR: MultiByte support must be enabled to use this function
That means I can't use psql on non-multibyte servers in that case.
(Probably true for other libpq applications, too.) I don't think that's
acceptable. Is there anything you can do there, such as the backend
ignoring whatever function is being called?
I believe you are going a little too far with ifdef'ing out MULTIBYTE. For
instance, it should be perfectly fine to call pg_char_to_encoding, even if
there's no possibility of using the encoding. Even when I don't configure
for multibyte support I should be able to use all (or at least most) of
the functions and get SQL_ASCII or 0 or some such back.
I will be interested to work with you and Thomas (and who knows else) on
the national character and related issues for the next release. Some of
this stuff needs a serious look.
--
Peter Eisentraut Sernanders väg 10:115
peter_e@gmx.net 75262 Uppsala
http://yi.org/peter-e/ Sweden