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 <[EMAIL PROTECTED]> 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. +
---------------------------(end of broadcast)---------------------------
TIP 4: Have you searched our list archives?
http://archives.postgresql.org
