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

Sat, 19 Feb 2000 14:14:02 +0900
Tatsuo Ishii <t-ishii@sra.co.jp>
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.

> 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


Sun, 20 Feb 2000 03:34:38 +0100 (CET)
Peter Eisentraut <peter_e@gmx.net>
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

Sun, 20 Feb 2000 13:15:54 +0900
Tatsuo Ishii <t-ishii@sra.co.jp>
Re: [HACKERS] new backslah command of psql
[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, Pennsylvania 19026

Sat, 19 Feb 2000 23:58:36 -0500 (EST)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: [HACKERS] new backslah command of psql
[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


Sun, 20 Feb 2000 17:25:10 +0900
Tatsuo Ishii <t-ishii@sra.co.jp>
Re: [HACKERS] new backslash command of psql
> [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, Pennsylvania 19026

Sun, 20 Feb 2000 16:50:51 -0500 (EST)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: [HACKERS] new backslash command of psql
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


Mon, 21 Feb 2000 20:48:08 +0100 (CET)
Peter Eisentraut <peter_e@gmx.net>
Re: [HACKERS] new backslash command of psql
[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, Pennsylvania 19026

Mon, 21 Feb 2000 14:58:59 -0500 (EST)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: [HACKERS] new backslash command of psql