I wrote:
> It looks to me like we have a very narrow problem and
> we should tailor a very narrow solution. What I am currently thinking
> we should do is make oper() specifically test for the case of operator
> 349 with UNKNOWN left input, or operator 374 with UNKNOWN right input,
> and throw a custom error message hinting that the other operand
> needs to be cast to text.
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 have no doubt that practically the only reasonable use-case for that
behavior was to let people concatenate stuff without being too picky
about casts, and this mostly preserves that ability. It's not perfect,
because it only fixes cases in which at least one operand is either
unknown or implicitly coercible to text. But in practice I think that
would cover 99% of cases, since typical usages tend to alternate
literals and data values.
Thoughts? Is this too klugy for words?
regards, tom lane
