Re: Domains versus polymorphic functions, redux

From: Noah Misch <noah(at)leadboat(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-hackers(at)postgreSQL(dot)org, lr(at)pcorp(dot)us
Subject: Re: Domains versus polymorphic functions, redux
Date: 2011-05-24 17:06:26
Message-ID: 20110524170626.GE21833@tornado.gateway.2wire.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, May 24, 2011 at 12:12:55PM -0400, Tom Lane wrote:
> In http://archives.postgresql.org/pgsql-bugs/2011-05/msg00171.php
> Regina Obe complains that this fails in 9.1, though it worked before:
>
> regression=# CREATE DOMAIN topoelementarray AS integer[];
> CREATE DOMAIN
> regression=# SELECT array_upper(ARRAY[[1,2], [3,4]]::topoelementarray, 1);
> ERROR: function array_upper(topoelementarray, integer) does not exist
>
> This is a consequence of the changes I made to fix bug #5717,
> particularly the issues around ANYARRAY matching discussed here:
> http://archives.postgresql.org/pgsql-hackers/2010-10/msg01545.php
>
> Regina is the second or third beta tester to complain about domains over
> arrays no longer matching ANYARRAY, so I think we'd better do something
> about it. I haven't tried to code anything up yet, but the ideas I'm
> considering trying to implement go like this:
>
> 1. If a domain type is passed to an ANYARRAY argument, automatically
> downcast it to its base type (which of course had better then be an
> array). This would include inserting an implicit cast into the
> expression tree, so that if the function uses get_fn_expr_argtype or
> similar, it would see the base type. Also, if the function returns
> ANYARRAY, its result is considered to be of the base type not the
> domain.

We discussed this a few weeks ago:
http://archives.postgresql.org/message-id/20110511093217.GB26552@tornado.gateway.2wire.net

What's to recommend #1 over what I proposed then? Seems like a discard of
functionality for little benefit.

> 2. If a domain type is passed to an ANYELEMENT argument, automatically
> downcast it to its base type if there is any ANYARRAY argument, or if
> the function result type is ANYARRAY, or if any other ANYELEMENT
> argument is not of the same domain type. The first two cases are
> necessary since we don't have arrays of domains: the match is guaranteed
> to fail if we don't do this, since there can be no matching array type
> for the domain. The third case is meant to handle cases like
> function(domain-over-int, 42) where the function has two ANYELEMENT
> arguments: we now fail, but reducing the domain to int would allow
> success.

This seems generally consistent with other function-resolution rules around
domains. On the other hand, existing users have supposedly coped by adding an
explicit cast to one or the other argument to get the behavior they want. New
applications will quietly get the cast, as it were, on the domain argument(s).
I hesitate to say this is so clearly right as to warrant that change. Even if
it is right, though, this smells like 9.2 material.

nm

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2011-05-24 17:11:59 Re: Domains versus polymorphic functions, redux
Previous Message Fujii Masao 2011-05-24 17:01:31 Cascade replication (WIP)