concatenating text and bytea
Hi,
I got recently bitten by this :
# select 'ascii'::text || E'\\xdeadbeef'::bytea, pg_typeof('ascii'::text ||
'\xdeadbeef'::bytea), 'ascii'::bytea || E'\\xdeadbeef'::bytea;
?column? | pg_typeof | ?column?
-----------------+-----------+----------------------
ascii\xdeadbeef | text | \x6173636969deadbeef
I would have expected a result cast as bytea or an error message telling me
about incompatible types, but the result from the first column is a nasty
gotcha. Is it the intented behaviour ?
--
Vincent de Phily
Vincent de Phily <vincent.dephily@mobile-devices.fr> writes:
I got recently bitten by this :
# select 'ascii'::text || E'\\xdeadbeef'::bytea, pg_typeof('ascii'::text ||
'\xdeadbeef'::bytea), 'ascii'::bytea || E'\\xdeadbeef'::bytea;
?column? | pg_typeof | ?column?
-----------------+-----------+----------------------
ascii\xdeadbeef | text | \x6173636969deadbeef
I would have expected a result cast as bytea or an error message telling me
about incompatible types, but the result from the first column is a nasty
gotcha. Is it the intented behaviour ?
Yes, it is. Personally I'd prefer this sort of thing to be rejected,
but allowing text concatenation to still accept non-text inputs was one
of the compromises that was made when we got rid of the former behavior
of implicitly casting to text in darn near *any* context:
http://git.postgresql.org/gitweb/?p=postgresql.git&a=commitdiff&h=31edbadf4af45dd4eecebcb732702ec6d7ae1819
http://git.postgresql.org/gitweb/?p=postgresql.git&a=commitdiff&h=2d4db3675fa7a2f4831b755bc98242421901042f
Considering the volume and the persistence of the complaints about that
change, I'm not about to propose tightening it up any more.
regards, tom lane