Re: Bug #728: Interactions between bytea and character encoding
От | Joe Conway |
---|---|
Тема | Re: Bug #728: Interactions between bytea and character encoding |
Дата | |
Msg-id | 3D4C81BF.1020703@joeconway.com обсуждение исходный текст |
Ответ на | Bug #728: Interactions between bytea and character encoding when doing analyze (pgsql-bugs@postgresql.org) |
Ответы |
Re: Bug #728: Interactions between bytea and character encoding when doing analyze
|
Список | pgsql-bugs |
Anders Hammarquist wrote: >>pgsql-bugs@postgresql.org writes: >> >>>If a byte string that is not valid unicode is inserted into a bytea >>>column, analyze will fail unless the data was tagged as bytea in the >>>insert. >> >>Your example produces no failure for me. You'd better be more specific >>about which PG version you're running, on what platform, with what >>configure options and what database encoding, etc. > Ah, sorry about that. It's 7.2.1, in the Debian package incarnation > 7.2.1-2. The database and the client encoding are both unicode. These > are the setting from postmaster.conf (nothing strange): I can confirm this is a problem on 7.2.1, but cvs tip works fine. It is not related to the form of the insert but rather the fact that with a one tuple table, pg_verifymbstr() never gets called (where the error is raised). In fact, textin never gets called either. But once there are two tuples, they do. Here's the backtrace from 7.2.1: Breakpoint 1, pg_verifymbstr (mbstr=0x837a698 "42", len=2) at wchar.c:541 541 if (pg_database_encoding_max_length() <= 1) (gdb) bt #0 pg_verifymbstr (mbstr=0x837a698 "42", len=2) at wchar.c:541 #1 0x08149c26 in textin (fcinfo=0xbfffeca0) at varlena.c:191 #2 0x08160579 in DirectFunctionCall1 (func=0x8149c00 <textin>, arg1=137864856) at fmgr.c:657 #3 0x080bbffa in update_attstats (relid=74723, natts=2, vacattrstats=0x8379f58) at analyze.c:1740 #4 0x080ba180 in analyze_rel (relid=74723, vacstmt=0x8378110) at analyze.c:350 . . . Joe
В списке pgsql-bugs по дате отправления: