On Fri, Jun 03, 2011 at 10:42:01AM -0400, Tom Lane wrote:
> Noah Misch <noah@leadboat.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