On Tue, May 24, 2011 at 2:54 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > "David E. Wheeler" <da...@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 life of 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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers