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