Vincent de Phily <vincent.dephily@xxxxxxxxxxxxxxxxx> 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
--
Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
