Re: Domains as Subtypes - Mailing list pgsql-hackers

TODO has:
* Allow user-defined functions retuning a domain value to enforce domain  constraints

Is there something we should add to this?

---------------------------------------------------------------------------

Tom Lane wrote:
> elein <elein@varlena.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
> 
> ---------------------------(end of broadcast)---------------------------
> TIP 2: Don't 'kill -9' the postmaster
> 

--  Bruce Momjian   http://candle.pha.pa.us EnterpriseDB    http://www.enterprisedb.com
 + If your life is a hard drive, Christ can be your backup. +