Re: Domains versus polymorphic functions, redux

On Tue, Jun 7, 2011 at 9:39 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Robert Haas <robertmhaas(at)gmail(dot)com> writes:
>> On Tue, Jun 7, 2011 at 6:28 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>>> Note that I changed coerce_type's behavior for both ANYARRAY and ANYENUM
>>> targets, but the latter behavioral change is unreachable since the other
>>> routines in parse_coerce.c will not match a domain-over-enum to ANYENUM.
>>> I am half tempted to extend the patch so they will, which would allow
>>> cases like this to work:
>>>
>>> regression=# select enum_first('green'::dcolor);
>>> ERROR:  function enum_first(dcolor) does not exist
>
>> Well, on the one hand, if we're doing it for arrays, it's hard to
>> imagine that the same behavior for enums can be an outright disaster.
>> On the flip side, people get reeeeeally cranky about changes that
>> break application code, so it would not be nice if we had to pull this
>> one back.  How likely is that?
>
> It's hard to see how allowing this match where there was no match before
> would break existing code.  A more plausible objection is that we'd be
> foreclosing any possibility of handling the match-domain-to-ANYENUM case
> differently, since once 9.1 had been out in the field doing this for a
> year, you can be sure there *would* be some apps depending on it.

Yes, that's the point I was trying to get at.

> So I think the real question is whether we have totally destroyed the
> argument for letting domains pass through polymorphic functions without
> getting smashed to their base types.  Personally I think that idea is
> pretty much dead in the water, but I sense that Noah hasn't given up on
> it yet ;-)  If we aren't yet willing to treat ANYELEMENT that way, maybe
> it's premature to adopt the stance for ANYENUM.

Given that we have no field demand for this behavior, maybe it's
better not to add it, so that we have the option later to change our
mind about how it should work.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company