On Fri, Jun 03, 2011 at 10:42:01AM -0400, Tom Lane wrote: > Noah Misch <n...@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.gb26...@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.ga29...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
