Re: [PATCHES] CURRENT CVS: MULTIBYTE: CANT CONNECT....
От | Karel Zak |
---|---|
Тема | Re: [PATCHES] CURRENT CVS: MULTIBYTE: CANT CONNECT.... |
Дата | |
Msg-id | 20010910082751.A14578@zf.jcu.cz обсуждение исходный текст |
Ответ на | Re: [PATCHES] CURRENT CVS: MULTIBYTE: CANT CONNECT.... (Tatsuo Ishii <t-ishii@sra.co.jp>) |
Ответы |
Re: [PATCHES] CURRENT CVS: MULTIBYTE: CANT CONNECT....
(Tatsuo Ishii <t-ishii@sra.co.jp>)
|
Список | pgsql-hackers |
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@zf.jcu.cz> http://home.zf.jcu.cz/~zakkr/ C, PostgreSQL, PHP, WWW, http://docs.linux.cz, http://mape.jcu.cz
В списке pgsql-hackers по дате отправления: