Обсуждение: new backslah command of psql
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. ------------------------------------------------------------------- o \eset <encoding> change the client encoding to <encoding>. This is actually PQsetClientEncoding + pset.encoding (psql internal data) change. Now user can change the client side encoding on the fly, that is not possible before 7.0. o \eshow show the client encoding. ------------------------------------------------------------------- -- Tatsuo Ishii
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
> 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
[Charset ISO-8859-1 unsupported, filtering to ASCII...] > 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. Do we have to have a \eset command? Can't we just use \set that we already have? -- Bruce Momjian | http://www.op.net/~candle pgman@candle.pha.pa.us | (610) 853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania19026
[spelling mistake in Subject corrected] > Do we have to have a \eset command? Can't we just use \set that we > already have? Not sure. Seems \set is for just setting a variable. To change the client encoding, we need to do more. -- Tatsuo Ishii
> [spelling mistake in Subject corrected] > > Do we have to have a \eset command? Can't we just use \set that we > > already have? > > Not sure. Seems \set is for just setting a variable. To change the > client encoding, we need to do more. We already have some special variable meanings like \set PROMPT1 which controls the psql prompt. Seems an encoding variable can be made too. -- Bruce Momjian | http://www.op.net/~candle pgman@candle.pha.pa.us | (610) 853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania19026
On 2000-02-20, Bruce Momjian mentioned: > We already have some special variable meanings like \set PROMPT1 which > controls the psql prompt. Seems an encoding variable can be made too. Setting the encoding actually has to *do* something though. The prompt will just be stored and read out next time it's needed. I guess one could include hooks into the set variable command, but I figured multibyte as we know it is going away soon anyway ... -- Peter Eisentraut Sernanders väg 10:115 peter_e@gmx.net 75262 Uppsala http://yi.org/peter-e/ Sweden
[Charset ISO-8859-1 unsupported, filtering to ASCII...] > On 2000-02-20, Bruce Momjian mentioned: > > > We already have some special variable meanings like \set PROMPT1 which > > controls the psql prompt. Seems an encoding variable can be made too. > > Setting the encoding actually has to *do* something though. The prompt > will just be stored and read out next time it's needed. I guess one could > include hooks into the set variable command, but I figured multibyte as we > know it is going away soon anyway ... > Oh, I though it didn't need hooks. Never mind. -- Bruce Momjian | http://www.op.net/~candle pgman@candle.pha.pa.us | (610) 853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania19026