From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | "David E(dot) Wheeler" <david(at)kineticode(dot)com> |
Cc: | pgsql-hackers(at)postgreSQL(dot)org, lr(at)pcorp(dot)us |
Subject: | Re: Domains versus polymorphic functions, redux |
Date: | 2011-05-24 18:54:16 |
Message-ID: | 13139.1306263256@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
"David E. Wheeler" <david(at)kineticode(dot)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?
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2011-05-24 19:05:18 | Re: Adding an example for replication configuration to pg_hba.conf |
Previous Message | Bruce Momjian | 2011-05-24 18:48:36 | Re: Adding an example for replication configuration to pg_hba.conf |