Обсуждение: Re: BUG #5477: CREATE DOMAIN NOT NULL constraints not always enforced for INSERT with subquery

Tom Lane  wrote:

< NOT NULL constraints at the domain level suck. Don't use 'em.

+1

As someone who uses domains very heavily, I can attest that the
semantics of that are very weak.  Whether a domain is nullable
depends almost entirely on the context of its use, which you can't
(and shouldn't try to) anticipate on its declaration.

-Kevin

Kevin Grittner wrote:
> Tom Lane  wrote:
>
> < NOT NULL constraints at the domain level suck. Don't use 'em.
>
> +1
>
> As someone who uses domains very heavily, I can attest that the
> semantics of that are very weak.  Whether a domain is nullable
> depends almost entirely on the context of its use, which you can't
> (and shouldn't try to) anticipate on its declaration.

Fair enough, thanks Tom and Kevin for the insights and thanks Bruce for
applying the doco patch, that makes things much clearer.

As NOT NULL on domains doesn't always prevent a value from becoming NULL
(and because it "sucks" :) ) would you consider deprecating the
not-null-on-domains feature and then removing it from some future
version of PostgreSQL?

Thanks again,
Matt

Matthew Nourse <matthew@nplus1.com.au> writes:
> As NOT NULL on domains doesn't always prevent a value from becoming NULL
> (and because it "sucks" :) ) would you consider deprecating the
> not-null-on-domains feature and then removing it from some future
> version of PostgreSQL?

We can't really because it's required by SQL standard.  Perhaps at some
point the standards committee will think it through a little better and
publish something that resolves the contradictions.  For the moment the
bottom line is that it's got debatable behavior and is best avoided.

            regards, tom lane

Tom Lane wrote:
> Matthew Nourse <matthew@nplus1.com.au> writes:
>> As NOT NULL on domains doesn't always prevent a value from becoming NULL
>> (and because it "sucks" :) ) would you consider deprecating the
>> not-null-on-domains feature and then removing it from some future
>> version of PostgreSQL?
>
> We can't really because it's required by SQL standard.  Perhaps at some
> point the standards committee will think it through a little better and
> publish something that resolves the contradictions.  For the moment the
> bottom line is that it's got debatable behavior and is best avoided.
>

Ah, I see.  Thanks again!

Matt