Thread: 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