Re: Implicit casts with generic arrays - Mailing list pgsql-hackers
From | Tom Lane |
---|---|
Subject | Re: Implicit casts with generic arrays |
Date | |
Msg-id | 20599.1181062948@sss.pgh.pa.us Whole thread Raw |
In response to | Re: Implicit casts with generic arrays (Tom Lane <tgl@sss.pgh.pa.us>) |
Responses |
Re: Implicit casts with generic arrays
|
List | pgsql-hackers |
I wrote: > I've been experimenting with another solution, which is to not add any > weird error cases but instead add operators that will capture the > problem cases back away from the anyelement||anyarray operators. > My current prototype is > create function catany(text, anyelement) returns text as > $$ select $1 || $2::text $$ language sql; > create function catany(anyelement, text) returns text as > $$ select $1::text || $2 $$ language sql; > create operator || (procedure = catany, leftarg = text, rightarg = anyelement); > create operator || (procedure = catany, leftarg = anyelement, rightarg = text); > which seems to mostly do the "right" thing. This approach would have > one nice property, namely eliminating the single biggest point of > push-back we are likely to get from removing the implicit casts to text. I've been testing this approach more, and finding that it really captures a bit too much: some cases that you'd prefer went to anyelement||anyarray will be captured by the text||anyelement operator. For example in 8.2 this is mapped to array_prepend: regression=# select 'x'::text || array['aa','bb','cc']; ?column? --------------{x,aa,bb,cc} (1 row) but with the experimental code you get textcat: catany=# select 'x'::text || array['aa','bb','cc']; ?column? -------------x{aa,bb,cc} (1 row) Basically the textcat operators will capture any case where the scalar side is implicitly coercible to text, because the type resolution rules will prefer that. There are some hacks we could make to make this less probable (eg, declare the capturing operators as taking varchar instead of text) but I can't find any complete solution short of changing the resolution rules themselves. Which I'm loath to do since it might have unexpected side-effects. What I would like to propose is that we deprecate use of || as the operator name for array_prepend and array_append, and invent new recommended names for them. As I said earlier, these operators aren't exactly concatenation in any normal sense anyway, since they don't treat their operands symmetrically. My first thought is to suggest using the shifting symbols: anyelement >> anyarray anyarray << anyelement but perhaps someone will have a better suggestion. If we do that, then we have a solution for anyone whose array prepend or append operator is unexpectedly captured by text concatenation: use the new names instead. Now this is only going to seem like a good idea if you agree that we should have some capturing operators like these. But if we don't, I think we are going to get a lot of push-back from people whose concatenations of random datatypes suddenly stopped working. Essentially this proposal is putting the compatibility hit of tightening the implicit cast rules onto people who are using array append/prepend instead of people who are using concatenation without explicit casts. I think there are a lot fewer of the former than the latter. Comments? regards, tom lane
pgsql-hackers by date: