Re: Domains versus polymorphic functions, redux

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

In response to

Responses

Browse pgsql-hackers by date

  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