På tirsdag 05. februar 2013 kl. 10:39:43, skrev Darren Duncan <darren@xxxxxxxxxxxxxxxx>:
Deferrable foreign key and unique key constraints I can understand, but ...
On 2013.02.05 1:22 AM, Andreas Joseph Krogh wrote:
> +100 for having NOT NULL and CHECK-constraints deferrable:-)
> Is there any "I want to sponsor development of <feature-X> with $xxx" mechanism?
I'd like to know what value there is in making NOT NULL and CHECK deferrable.
While we're at it, do we want to make the column data type check constraints
deferrable too, so you can initially assign any value at all without regard for
the declared type of the column? Then we only at constraints-immediate time
say, sorry, you can't put a string in a number column, or, sorry, that number is
too large, or that string is too long, or whatever.
NOT NULL and CHECK constraints are effectively just part of a data type
definition after all. Postgres' current behavior is fairly consistent; if we
make these deferrable, then why stop there?
The value of having NOT NULL deferrable is, well, to not check for NULL until the tx commits. When working with ORMs this often is the case, especially with circular FKs.
--
Andreas Joseph Krogh <andreak@xxxxxxxxxxxx> mob: +47 909 56 963
Senior Software Developer / CTO - OfficeNet AS - http://www.officenet.no
Public key: http://home.officenet.no/~andreak/public_key.asc
Andreas Joseph Krogh <andreak@xxxxxxxxxxxx> mob: +47 909 56 963
Senior Software Developer / CTO - OfficeNet AS - http://www.officenet.no
Public key: http://home.officenet.no/~andreak/public_key.asc
