Re: [HACKERS] new backslah command of psql

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

Ok.

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

Ok.

>Also you can do \echo :ENCODING.
> That fits in better with the rest.

Oh, I didn't know that.

> 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 can hardly imagine the case where multibyte-enabled/non-multibyte
installations are mixed together. Anyway, we could enable part of
multibyte functions even if it not configured. But is it worth to do
that?

I personally think that MULTIBYTE should always be enabled since it is
"upper compatible" to non-MB installations and no significant
performance penalty is observed (I am not sure about what other core
developers are thinking, though).

Moreover, we are going to implement the national character etc. in the
near future and the current multibyte implementations will be
deprecated soon.

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

Yes, especially to introduce CREATE CHARACTER SET, current MB stuffs
must be completely rewritten.
--
Tatsuo Ishii