Re: Domains as Subtypes

elein <elein(at)varlena(dot)com> writes:
> On Mon, Mar 27, 2006 at 11:41:30AM -0500, Tom Lane wrote:
>> I remembered the problem with doing it that way: an input function can't
>> enforce a domain NOTNULL constraint, because it won't even get invoked
>> for a null input value. So there seems no way around having a special
>> case for domains in all places where I/O conversion is done.

> The notnull attribute of the pg_type table should be set to not null
> in the case of a not null constraint on a domain (type).
> You should not have to invoke the input function to check for that.
> Or perhaps I'm missing the details.

Well, I can see two problems:

1. If we have to add code to everyplace that calls an input function to
do that, then we've failed to achieve the hoped-for goal of solving the
problem in just one place.

2. NOTNULL is just the most obvious form of the problem. There could be
domain CHECK constraints that fail on null input --- CHECK(VALUE IS NOT
NULL) for example, or something more subtle. If we don't run the input
function then this means the CHECK constraints also have to be done
out-of-band, and then we've lost any leverage whatsoever.

We could push the problem into a domain input function if we abandoned
the current rule that input functions are never invoked for nulls (we
could check their strictness flag to decide whether to do it). This
sort of change seems distinctly cleaner than pushing explicit knowledge
about domains into all the places that use input functions, but it's
still pretty ugly:

A. We still have to touch everyplace that uses an input function; any
code not changed will simply do the Wrong Thing for nulls, which is not
a very friendly failure mode. (And we know there are places outside the
core that use this stuff, for instance non-core PLs.)

B. C-language input functions for most datatypes will need to be
declared strict, else they'll crash on null input, which is an even
less friendly behavior. Again, we can't be sure that non-core datatypes
get this right at present.

regards, tom lane