Re: concatenating text and bytea
| От | Tom Lane |
|---|---|
| Тема | Re: concatenating text and bytea |
| Дата | |
| Msg-id | 9938.1330714730@sss.pgh.pa.us обсуждение исходный текст |
| Ответ на | concatenating text and bytea (Vincent de Phily <vincent.dephily@mobile-devices.fr>) |
| Список | pgsql-general |
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
В списке pgsql-general по дате отправления: