Re: [HACKERS] CURRENT CVS: MULTIBYTE: CANT CONNECT....

Tatsuo, I applied this patch.  Please fix as needed.


> > > > > CC=cc CXX=CC ./configure  --prefix=/usr/local/pgsql --enable-syslog \
> > > > >     --with-CXX --with-perl --enable-multibyte --enable-cassert \
> > > > >     --with-includes=/usr/local/include --with-libs=/usr/local/lib \
> > > > >     --enable-debug \
> > > > >     --with-tcl --with-tclconfig=/usr/local/lib \
> > > > >     --with-tkconfig=/usr/local/lib  --enable-locale
> > > > > and when I try to connect to an existing DB, loaded from a pg_dump
> > > > > from the previous 7.2devel sources, I get:
> > > > > TRAP: Failed Assertion("!(ClientEncoding):", File: "mbutils.c", Line:
> > > > > 314)
> > > > > !(ClientEncoding) (0) [No such file or directory]
> > > >
> > > >  Interesting. I don't know why, but someting don't call
> > > > pg_set_client_encoding() before usage encoding routines (maybe
> > > > libpq don't set client encoding if it's default SQL_ASCII, but
> > > > I'm almost sure that I check this case).
> > > >
> > > >  A simple and robus solution is in the begin of mbutils.c set default
> > > > ClientEncoding to SQL_ASCII (like default DatabaseEncoding). Bruce, can
> > > > you change it? It's one line change. Again thanks.
>
> Karel,
>
> The bug Larry reported seems for such a case of connecting non
> existent database. The backend tries to send the error message to the
> frontend using pg_server_to_client WITHOUT getting an encoding info
> from the database. To fix this Larry's patch or you stat in the
> previous mail are sufficient. I will commit the fix.
>
> >  Forget it! A default client encoding must be set by actual database encoding...
>
> Why? set_default_client_encoding does the job anyway.
> --
> Tatsuo Ishii
>

--
  Bruce Momjian                        |  http://candle.pha.pa.us
  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