From: | Karel Zak <zakkr(at)zf(dot)jcu(dot)cz> |
---|---|
To: | Tatsuo Ishii <t-ishii(at)sra(dot)co(dot)jp> |
Cc: | pgman(at)candle(dot)pha(dot)pa(dot)us, pgsql-hackers(at)postgresql(dot)org, pgsql-patches(at)postgresql(dot)org |
Subject: | Re: [PATCHES] CURRENT CVS: MULTIBYTE: CANT CONNECT.... |
Date: | 2001-09-10 06:27:52 |
Message-ID: | 20010910082751.A14578@zf.jcu.cz |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs pgsql-hackers pgsql-patches |
On Sat, Sep 08, 2001 at 11:51:24PM +0900, Tatsuo Ishii wrote:
> > > > > 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.
Here can't be used static default encoding as for DatabaseEncoding, because
typical code is
if (!ClientEncoding)
/* ...means "if user doesn't set itself client
* encoding by SET command"
*/
ClientEncoding = DatabaseEncoding;
and if you set anywhere before this as default
ClientEncoding = &pg_enc2name_tbl[ PG_SQL_ASCII ]; the ClientEncoding will
always TRUE and always SQL_ASCII and the only way is change it by 'SET
CLIENT_ENCODING' command. But we don't want it, wanted is after connection
set as default ClientEncoding same encoding as actual DabaseEncoding.
Karel
--
Karel Zak <zakkr(at)zf(dot)jcu(dot)cz>
http://home.zf.jcu.cz/~zakkr/
C, PostgreSQL, PHP, WWW, http://docs.linux.cz, http://mape.jcu.cz
From | Date | Subject | |
---|---|---|---|
Next Message | Tatsuo Ishii | 2001-09-10 06:50:46 | Re: [PATCHES] CURRENT CVS: MULTIBYTE: CANT CONNECT.... |
Previous Message | pgsql-bugs | 2001-09-09 14:58:04 | Bug #445: SQLDescribeCol() returns "wrong" info |
From | Date | Subject | |
---|---|---|---|
Next Message | Tatsuo Ishii | 2001-09-10 06:40:16 | COMMENT ON |
Previous Message | Tatsuo Ishii | 2001-09-10 05:12:06 | Re: factorial doc bug? |
From | Date | Subject | |
---|---|---|---|
Next Message | Tatsuo Ishii | 2001-09-10 06:50:46 | Re: [PATCHES] CURRENT CVS: MULTIBYTE: CANT CONNECT.... |
Previous Message | Bradley McLean | 2001-09-10 02:34:29 | Add relid to TD in plpython |