Re: Domains versus polymorphic functions, redux - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Domains versus polymorphic functions, redux
Date
Msg-id 13139.1306263256@sss.pgh.pa.us
Whole thread Raw
In response to Re: Domains versus polymorphic functions, redux  ("David E. Wheeler" <david@kineticode.com>)
Responses Re: Domains versus polymorphic functions, redux  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
"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?
        regards, tom lane


pgsql-hackers by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: Adding an example for replication configuration to pg_hba.conf
Next
From: Robert Haas
Date:
Subject: Re: Adding an example for replication configuration to pg_hba.conf