Обсуждение: odd convert_from bug

The case below has just been reported to me. It sure looks odd. I'm 
looking into it but any ideas would be welcome. The problem only occurs 
if we are updating more than one row.

cheers

andrew


andrew=# select getdatabaseencoding();getdatabaseencoding
---------------------UTF8
(1 row)

andrew=# create table qqq(x text);
CREATE TABLE
andrew=# insert into qqq values('a');
INSERT 0 1
andrew=# update qqq set x = 
convert_from(decode('50696f74726bf3772c20506f6c616e64','hex'),'latin9');
UPDATE 1
andrew=# insert into qqq values('a');
INSERT 0 1
andrew=# update qqq set x = 
convert_from(decode('50696f74726bf3772c20506f6c616e64','hex'),'latin9') 
where x = 'a';
UPDATE 1
andrew=# insert into qqq values('a');
INSERT 0 1
andrew=# insert into qqq values('b');
INSERT 0 1
andrew=# update qqq set x = 
convert_from(decode('50696f74726bf3772c20506f6c616e64','hex'),'latin9') 
where x = 'a';
UPDATE 1
andrew=# insert into qqq values('c');
INSERT 0 1
andrew=# update qqq set x = 
convert_from(decode('50696f74726bf3772c20506f6c616e64','hex'),'latin9') ;
ERROR:  encoding name too long
andrew=#

Andrew Dunstan <andrew@dunslane.net> writes:
> The case below has just been reported to me. It sure looks odd. I'm 
> looking into it but any ideas would be welcome. The problem only occurs 
> if we are updating more than one row.

Pfree'ing something you didn't palloc is bad news...
        regards, tom lane

Tom Lane wrote:
> Andrew Dunstan <andrew@dunslane.net> writes:
>   
>> The case below has just been reported to me. It sure looks odd. I'm 
>> looking into it but any ideas would be welcome. The problem only occurs 
>> if we are updating more than one row.
>>     
>
> Pfree'ing something you didn't palloc is bad news...
>   

Ah, yes, thanks, looks like I was a little too eager on the C&P. I see 
you have fixed it.

cheers

andrew

Andrew Dunstan wrote:
>
>
> Tom Lane wrote:
>> Andrew Dunstan <andrew@dunslane.net> writes:
>>  
>>> The case below has just been reported to me. It sure looks odd. I'm 
>>> looking into it but any ideas would be welcome. The problem only 
>>> occurs if we are updating more than one row.
>>>     
>>
>> Pfree'ing something you didn't palloc is bad news...
>>   
>
> Ah, yes, thanks, looks like I was a little too eager on the C&P. I see 
> you have fixed it.
>
>

BTW, if calling pfree() at all here is actually a bug, then we should 
probably fix it in the back branches. It looks more to me like the 
problem was that pg_convert_from was calling pfree() with the wrong 
argument - src_encoding_name instead of dest_encoding_name. But maybe 
the pfree in the back branches is unnecessary but harmless.

cheers

andrew

Andrew Dunstan <andrew@dunslane.net> writes:
> BTW, if calling pfree() at all here is actually a bug, then we should 
> probably fix it in the back branches. It looks more to me like the 
> problem was that pg_convert_from was calling pfree() with the wrong 
> argument - src_encoding_name instead of dest_encoding_name.

Right.  I just took it out because it wasn't really that useful;
in general SQL-callable functions can expect that they're called in
fairly short-lived contexts, and so retail pfree's aren't very
interesting unless you're talking about large chunks.

BTW, just for the record, the "(void *)" casts were poor style
too IMHO --- DatumGetPointer() would be better.
        regards, tom lane