Since our shop seems to use domains more than most, I figured I
should comment on this thread.
>Sam Mason <sam(at)samason(dot)me(dot)uk> wrote:
>> On Tue, Sep 15, 2009 at 02:54:18PM +0100, Andrew Gierth wrote:
>> 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.
OK by me.
> Although it gives me the feeling that domains are more
> and more like a mis-designed feature.
They have their place, for when you don't really need a new type,
but you want to show that multiple columns contain data from the
same set. My rule of thumb is this -- if it would make sense for
two columns to be compared for equality, there's a very good chance
they belong in the same domain; if not, they probably don't. Using
them helps to document complex databases and helps with portability,
quite aside from the issue of constraints.
> 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.
If that's what the spec says, then +1 from me. The change won't
cause problems here.
-Kevin