Re: [HACKERS] new backslah command of psql
От | Tatsuo Ishii |
---|---|
Тема | Re: [HACKERS] new backslah command of psql |
Дата | |
Msg-id | 20000220131554B.t-ishii@sra.co.jp обсуждение исходный текст |
Ответ на | Re: [HACKERS] new backslah command of psql (Peter Eisentraut <peter_e@gmx.net>) |
Список | pgsql-hackers |
> 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
В списке pgsql-hackers по дате отправления: