Re: [BUGS] BUG #5053: domain constraints still leak - Mailing list pgsql-hackers

From Sam Mason
Subject Re: [BUGS] BUG #5053: domain constraints still leak
Date
Msg-id 20090915141942.GC5407@samason.me.uk
Whole thread Raw
In response to Re: [BUGS] BUG #5053: domain constraints still leak  (Andrew Gierth <andrew@tao11.riddles.org.uk>)
Responses Re: [BUGS] BUG #5053: domain constraints still leak
List pgsql-hackers
On Tue, Sep 15, 2009 at 02:54:18PM +0100, Andrew Gierth wrote:
> the spec _does_ appear to allow CHECK(VALUE IS NOT NULL) as a
> domain constraint (in general the spec defines NOT NULL constraints
> this way),

Huh, that's a trivial rewrite isn't it.  Not sure why it didn't occur to
me that it's just syntax sugar.

> and the wording from 6.12 implies that that check is still
> skipped in the case of NULLs (so that constraint would stop you
> inserting a null into a table column (I think), but not from casting a
> null value to the domain type).

Explicitly ignoring NULL values in CAST expressions seems like a good
feature as well.  Although it gives me the feeling that domains are more
and more like a mis-designed feature.

> >>>>> "Sam" == Sam Mason <sam@samason.me.uk> writes:
>  Sam> The NOT NULL constraint feels wrong as well, 

> I think that's just another example of Tom's initial comment about how
> broken domain "not null" constraints are currently.

Hum, given that it's just sugar for more general constraints I'm not
sure if it's the not null constraints that are broken or just the
current interpretation of them.  They would do the "right thing" if they
were only checked in a limited number of places that the user was aware
of, which the spec seems to imply is when the user explicitly asks for a
CAST to be performed or when writing into the table.

--  Sam  http://samason.me.uk/


pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: CommitFest 2009-09: Now In Progress
Next
From: "Kevin Grittner"
Date:
Subject: Re: Timestamp to time_t