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