Skip site navigation (1) Skip section navigation (2)

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

From: Joe Conway <mail(at)joeconway(dot)com>
To: Anders Hammarquist <iko(at)strakt(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-bugs(at)postgresql(dot)org
Subject: Re: Bug #728: Interactions between bytea and character encoding
Date: 2002-08-04 01:22:07
Message-ID: 3D4C81BF.1020703@joeconway.com (view raw or flat)
Thread:
Lists: pgsql-bugs
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


In response to

Responses

pgsql-bugs by date

Next:From: Tom LaneDate: 2002-08-04 02:13:21
Subject: Re: "analyze" putting wrong reltuples in pg_class
Previous:From: the kay (efesar)Date: 2002-08-04 01:13:25
Subject: PG_DUMP / PG_RESTORE

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group