From: | Stephen Davies <scldad(at)sdc(dot)com(dot)au> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | pgsql-general(at)postgresql(dot)org |
Subject: | Re: Null records inserted |
Date: | 2001-03-24 08:09:34 |
Message-ID: | 200103240809.SAA24788@mustang.sdc.com.au |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
Thanks Tom.
I'm not sure how an explicit null can be being specified but it sounds
like a plausible explanation. Now off to battle with VB;-(
Cheers,
Stephen Davies
On Fri, 23 Mar 2001 22:33:47 -0500, Tom Lane said:
> Stephen Davies <scldad(at)sdc(dot)com(dot)au> writes:
> > That is, how can a field that is defined as having a default value wind
> > up in the database as null.
>
> Via an explicit specification of a NULL field value in an INSERT.
> A default value does not override an explicit specification.
>
> > Despite the usual rules regarding null processing, I would still expect
> > a second unique primary key value of null to be rejected.
>
> If you had actually declared it as a primary key (which implies NOT
> NULL) then even one null would be disallowed. However a unique
> constraint without NOT NULL does not disallow nulls, even multiple ones.
> There's been some discussion about whether that's the correct behavior,
> but that's how it works at the moment.
>
> regards, tom lane
========================================================================
Stephen Davies Consulting scldad(at)sdc(dot)com(dot)au
Adelaide, South Australia. Voice: 08-8177 1595
Computing & Network solutions. Fax: 08-8177 0133
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Eisentraut | 2001-03-24 09:38:04 | Re: Call for platforms |
Previous Message | Tom Lane | 2001-03-24 03:33:47 | Re: Null records inserted |