On Tue, May 24, 2011 at 2:54 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> "David E. Wheeler" <david@kineticode.com> writes:
>> On May 24, 2011, at 11:30 AM, Tom Lane wrote:
>>> I guess that the question that's immediately at hand is sort of a
>>> variant of that, because using a polymorphic function declared to take
>>> ANYARRAY on a domain-over-array really is using a portion of the base
>>> type's functionality. What we've learned from bug #5717 and the
>>> subsequent issues is that using that base functionality without
>>> immediately abandoning the notion that the domain has some life of its
>>> own (ie, immediately casting to the base type) is harder than it looks.
>
>> Well, in the ANYELEMENT context (or ANYARRAY), what could be lost by "abandoning the notion that the domain has some
lifeof its own"?
>
> I'm starting to think that maybe we should separate the two cases after
> all. If we force a downcast for ANYARRAY matching, we will fix the loss
> of functionality induced by the bug #5717 patch, and it doesn't seem
> like anyone has a serious objection to that. What to do for ANYELEMENT
> seems to be a bit more controversial, and at least some of the proposals
> aren't reasonable to do in 9.1 at this stage. Maybe we should just
> leave ANYELEMENT as-is for the moment, and reconsider that issue later?
If we haven't lost any functionality with respect to ANYELEMENT in
9.1, then I don't think we ought to try to improve/change/break it in
9.1 either. But I do think we need to do something about ANYARRAY
matching, and your proposed fix seems pretty reasonable to me.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
