Since our shop seems to use domains more than most, I figured I should comment on this thread.
>Sam Mason <s...@samason.me.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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
