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?