Gregory Stark <stark@enterprisedb.com> writes:
> "Tom Lane" <tgl@sss.pgh.pa.us> writes:
>> 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.
> Wouldn't that mean that 'foo'||'bar' would *still* fail?
No, because that would preferentially match to text || text, it being
a preferred-type case. The current behavior with the implicit casts
removed is
template1=# select 'abc' || '34';?column?
----------abc34
(1 row)
ie, this was matched to the text || text operator;
template1=# select 'abc' || 34;
ERROR: array value must start with "{" or dimension information
ie, this was matched to the anyarray || anyelement operator --- because
it clearly can't match text || text.
> It really seems to me that at some point down the line we're going to
> cave and admit that users do expect 'foo' to be a string first and
> cast to other types only if the context requires it.
We already do that to some extent, as shown above; and it's got
approximately nothing to do with this problem anyway. The cases where
we have got a problem are where the other argument is clearly *not*
text.
But having said that, I'm currently leaning to the other solution of
generalizing the || operator (and only that operator) instead of
fooling with the type resolution rules.
regards, tom lane
