Polymorphic types vs. domains

The proximate cause of this complaint:
http://archives.postgresql.org/pgsql-general/2008-12/msg00283.php
seems to be that the polymorphic-type code doesn't consider a domain
over an enum type to match an ANYENUM function argument.

ISTM this is probably wrong: we need such a domain to act like its base
type for matching purposes. There is an analogous problem with a domain
over an array type failing to match ANYARRAY; conversely, such a domain
is considered to match ANYNONARRAY which it likely should not.

Comments? If this is agreed to be a bug, should we consider
back-patching it? (I'd vote not, I think, because the behavioral
change could conceivably break some apps that work now.)

regards, tom lane

On Dec 8, 2008, at 2:46 AM, Tom Lane wrote:

> Comments?

+1

> If this is agreed to be a bug, should we consider
> back-patching it? (I'd vote not, I think, because the behavioral
> change could conceivably break some apps that work now.)

+1

Best,

David

How would it break any apps? They would hve to be depending on passing
arrays as anynonarray? That seems unlikely.

On the other hand I don't see much reason to backpatch. It's not like
anyone is going to run into this problem unexpectedly on a running
system. It just doesn't seem like a back patchable bug fix.

--
Greg

On 8 Dec 2008, at 08:00, "David E. Wheeler" <david(at)kineticode(dot)com>
wrote:

> On Dec 8, 2008, at 2:46 AM, Tom Lane wrote:
>
>> Comments?
>
> +1
>
>> If this is agreed to be a bug, should we consider
>> back-patching it? (I'd vote not, I think, because the behavioral
>> change could conceivably break some apps that work now.)
>
> +1
>
> Best,
>
> David
>
>
> --
> Sent via pgsql-hackers mailing list (pgsql-hackers(at)postgresql(dot)org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-hackers

Greg Stark <greg(dot)stark(at)enterprisedb(dot)com> writes:
> How would it break any apps?

Well, this would change the set of possible matches for ambiguous
function calls. So it's not out of the question that you could get
ambiguous-function failures that didn't happen before.

regards, tom lane

To be honest, for me back patching would mean only that I don't have
to recompile, and resend binaries to clients, after 8.1->8.3 upgrade
(to utilize enums, and domains).
I don't think it would break any apps tho.

so in my case, obviously +1 +1 :)

any news on that front ?

Where are we on this? I tested CVS and the problem still seems to
exist.

---------------------------------------------------------------------------

Tom Lane wrote:
> The proximate cause of this complaint:
> http://archives.postgresql.org/pgsql-general/2008-12/msg00283.php
> seems to be that the polymorphic-type code doesn't consider a domain
> over an enum type to match an ANYENUM function argument.
>
> ISTM this is probably wrong: we need such a domain to act like its base
> type for matching purposes. There is an analogous problem with a domain
> over an array type failing to match ANYARRAY; conversely, such a domain
> is considered to match ANYNONARRAY which it likely should not.
>
> Comments? If this is agreed to be a bug, should we consider
> back-patching it? (I'd vote not, I think, because the behavioral
> change could conceivably break some apps that work now.)
>
> regards, tom lane
>
> --
> Sent via pgsql-hackers mailing list (pgsql-hackers(at)postgresql(dot)org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-hackers

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +

Tom Lane wrote:
> The proximate cause of this complaint:
> http://archives.postgresql.org/pgsql-general/2008-12/msg00283.php
> seems to be that the polymorphic-type code doesn't consider a domain
> over an enum type to match an ANYENUM function argument.
>
> ISTM this is probably wrong: we need such a domain to act like its base
> type for matching purposes. There is an analogous problem with a domain
> over an array type failing to match ANYARRAY; conversely, such a domain
> is considered to match ANYNONARRAY which it likely should not.
>
> Comments? If this is agreed to be a bug, should we consider
> back-patching it? (I'd vote not, I think, because the behavioral
> change could conceivably break some apps that work now.)

This has not been addressed yet.

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +