From: | Noah Misch <noah(at)leadboat(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Robert Haas <robertmhaas(at)gmail(dot)com>, pgsql-hackers(at)postgresql(dot)org, lr(at)pcorp(dot)us |
Subject: | Re: Domains versus polymorphic functions, redux |
Date: | 2011-06-03 17:53:23 |
Message-ID: | 20110603175323.GC30150@tornado.leadboat.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Fri, Jun 03, 2011 at 10:42:01AM -0400, Tom Lane wrote:
> Noah Misch <noah(at)leadboat(dot)com> writes:
> > On Fri, Jun 03, 2011 at 12:27:35AM -0400, Robert Haas wrote:
> >> and we
> >> treat the call as a request to smash bar to the underlying array type.
>
> > No, there's no need to do that. The domain "is" an array, not merely
> > something that can be coerced to an array. Therefore, it can be
> > chosen as the polymorphic type directly. Indeed, all released
> > versions do this.
>
> No, it cannot "be chosen as the polymorphic type directly".
This already happens today.
> The problem
> with that is that there is no principled way to resolve ANYELEMENT
> unless you consider that you have downcasted the domain to the array
> type.
I have nothing material to add to my statement in
http://archives.postgresql.org/message-id/20110511093217.GB26552@tornado.gateway.2wire.net
Let's be concrete; run this on 9.0:
CREATE DOMAIN foo AS int[];
SELECT pg_typeof(array_append('{1}'::foo, 1));
SELECT pg_typeof(array_prepend(1, '{1}'::foo));
SELECT pg_typeof(array_fill(1, array[3]));
Which of those type resolutions do you find unprincipled, or what hypothetical
function does 9.0 resolve in an unprincipled way? (What the function actually
does isn't important.)
> You could perhaps ignore that problem for polymorphic functions
> that use only ANYARRAY and not ANYELEMENT in their arguments and return
> type --- but I'm not happy with the idea that that case would work
> differently from a function that does use both.
It would be no good to bifurcate the rules that way.
> So far as the other points you raise are concerned, I'm still of the
> opinion that we might be best off to consider that domains should be
> smashed to their base types when matching them to ANYELEMENT, too.
> Again, if we don't do that, we have a problem with figuring out what
> ANYARRAY ought to be (since we don't create an array type to go with a
> domain).
Perhaps, though it paints us into a backward compatibility corner should we ever
support arrays of domains. How many field complaints has the longstanding error
outcome produced?
> More generally, this dodges the whole problem of needing
> polymorphic functions to enforce domain constraints, something I still
> believe is entirely impractical from an implementation standpoint.
I wrote about the implementation scope in
http://archives.postgresql.org/message-id/20110511191249.GA29592@tornado.gateway.2wire.net
While I don't doubt the presence of implementation challenges beyond those I
identified, we can't meaningfully discuss them as generalities.
nm
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 2011-06-03 18:01:41 | Remove support for 'userlocks'? |
Previous Message | Thom Brown | 2011-06-03 17:45:57 | Re: creating CHECK constraints as NOT VALID |