From: | Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | elein <elein(at)varlena(dot)com>, Jim Nasby <jnasby(at)pervasive(dot)com>, josh(at)agliodbs(dot)com, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Domains as Subtypes |
Date: | 2006-04-10 20:25:22 |
Message-ID: | 200604102025.k3AKPM124328@candle.pha.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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(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
>
> ---------------------------(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. +
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 2006-04-10 21:27:45 | Re: Remote administration contrib module |
Previous Message | Bruce Momjian | 2006-04-10 19:41:59 | Re: Role incompatibilities |