Tom Lane wrote:
> 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?
On the contrary, I would think that it fits nicely to "close the loop"
on the anyarray/anyelement feature set.
--
Alvaro Herrera http://www.CommandPrompt.com/
PostgreSQL Replication, Consulting, Custom Development, 24x7 support