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". 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. 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.
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). 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.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
