Re: Domains versus polymorphic functions, redux

Peter Eisentraut <peter_e(at)gmx(dot)net> writes:
> What you are looking for is the SQL feature called "distinct types".
> The makers of the SQL standard have sort of deprecated domains in favor
> of distinct types, because distinct types address your sort of use case
> better, and prescribing the behavior of domains becomes weirder and
> weirder as the type system becomes more complex. Which is pretty much
> the same experience we've been having over the years.

Yeah ... the one thing that is actually completely broken about (our
current interpretation of) domains is that a first-class SQL datatype
cannot sanely have a NOT NULL constraint attached to it. That just
doesn't work in conjunction with outer joins, to take one glaring
example.

As I mentioned upthread, a closer look at the standard leads me to think
that the committee doesn't actually intend that a domain's constraints
follow it through operations --- I now think they only intend that the
constraints get checked in the context of a cast to the domain
(including assignment casts). In our terminology that would mean that a
domain gets downcast to its base type as soon as you do anything at all
to the value, even just pass it through a join.

There are certainly applications where such a behavior isn't what you
want, but trying to force domains to do something else is just not going
to lead to desirable results. It's better to invent some other concept,
and it sounds like the committee reached the same conclusion.

Anyway, I think we're out of time to do anything about the issue for
9.1. I think what we'd better do is force a downcast in the context
of matching to an ANYARRAY parameter, and leave the other cases to
revisit later.

regards, tom lane