Re: Implicit casts with generic arrays

Joe Conway <mail(at)joeconway(dot)com> writes:
> Tom Lane wrote:
>> In the long run maybe we should choose some other name for the
>> array_append and array_prepend operators to avoid the confusion with
>> concatenation. It seems to me that "concatenation" normally implies
>> "stringing together similar objects", which these two operators
>> definitely don't do, and so you could argue that || was a bad name
>> for them from the get-go.

> Originally I saw this situation as as requiring the concatenation
> operator per SQL 2003:

Maybe I am missing something, but the only such construct I see in
SQL2003 is concatenation of arrays of equal rank. There is nothing
corresponding to array_prepend or array_append.

I do have a plan B if people don't want to rename the operators, though.
It looks to me like we could eliminate the conflict if we invented a new
polymorphic pseudotype called "anynonarray" or some such, which would
act like anyelement *except* it would not match an array. Then,
declaring the capturing operators as text||anynonarray and
anynonarray||text would prevent them from matching any case where either
side was known to be an array type. But they would (I think) still win
out in cases such as scalar || 'unknown literal'. The end result would
be that concatenations involving a known-array value would be array
concatenation, but you could force them to be text concatenation, if
that's what you wanted, by explicitly casting the array value(s) to text.

I was a bit hesitant to propose this since I couldn't immediately think
of any other use-case for such a pseudotype. It's not a huge amount of
added code (cf. anyenum) but it's definitely a visible wart on the type
system. Comments?

regards, tom lane