Re: Bug #728: Interactions between bytea and character encoding

Anders Hammarquist wrote:
>>pgsql-bugs(at)postgresql(dot)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