Re: Domains versus polymorphic functions, redux

On Tue, Jun 7, 2011 at 6:28 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> I wrote:
>> Anyway, I think we're out of time to do anything about the issue for
>> 9.1.  I think what we'd better do is force a downcast in the context
>> of matching to an ANYARRAY parameter, and leave the other cases to
>> revisit later.
>
> Attached is a draft patch to do the above.  It's only lightly tested,
> and could use some regression test additions, but it seems to fix
> Regina's complaint.
>
> 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=#  create type color as enum('red','green','blue');
> CREATE TYPE
> regression=# select enum_first('green'::color);
>  enum_first
> ------------
>  red
> (1 row)
>
> regression=# create domain dcolor as color;
> CREATE DOMAIN
> regression=# select enum_first('green'::dcolor);
> ERROR:  function enum_first(dcolor) does not exist
> LINE 1: select enum_first('green'::dcolor);
>               ^
> HINT:  No function matches the given name and argument types. You might need to add explicit type casts.
>
> I'm unsure though if there's any support for this further adventure,
> since it wouldn't be fixing a 9.1 regression.
>
> Comments?

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?

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