P=C3=A5 tirsdag 05. februar 2013 kl. 10:39:43, skrev Darren Duncan <=
;darren@darren=
duncan.net>:
<blockquote style=3D"border-left: 1px solid rgb(204, 204, 204); margin: 0pt=
0pt 0pt 0.8ex; padding-left: 1ex;">
Def=
errable 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 deferrabl=
e.
While we're at it, do we want to make the column data type check constraint=
s
deferrable too, so you can initially assign any value at all without regard=
for
the declared type of the column?=C2=A0 Then we only at constraints-immediat=
e time
say, sorry, you can't put a string in a number column, or, sorry, that numb=
er 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.=C2=A0 Postgres' current behavior is fairly consistent=
; if we
make these deferrable, then why stop there?
=C2=A0
The value of having NOT NULL deferrable is, well, to not check for NUL=
L until the tx commits. When working with ORMs this often is the case, espe=
cially with circular FKs.
=C2=A0
--
Andreas Joseph Krogh <andreak@officenet.no>=C2=A0 =C2=A0 =C2=A0 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
=C2=A0=