Robert Haas <robertmh...@gmail.com> writes:
> On Tue, Jun 7, 2011 at 6:28 PM, Tom Lane <t...@sss.pgh.pa.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.
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.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
