Skip site navigation (1) Skip section navigation (2)

Re: Implicit casts with generic arrays

From: Alvaro Herrera <alvherre(at)commandprompt(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Joe Conway <mail(at)joeconway(dot)com>, Peter Eisentraut <peter_e(at)gmx(dot)net>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Implicit casts with generic arrays
Date: 2007-06-06 14:36:59
Message-ID: 20070606143659.GE6377@alvh.no-ip.org (view raw or flat)
Thread:
Lists: pgsql-hackers
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

In response to

Responses

pgsql-hackers by date

Next:From: Bruce MomjianDate: 2007-06-06 14:41:23
Subject: Re: TOAST usage setting
Previous:From: Tom LaneDate: 2007-06-06 14:21:32
Subject: Re: Implicit casts with generic arrays

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group