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 ---------------------------(end of broadcast)--------------------------- TIP 4: Have you searched our list archives? http://archives.postgresql.org
