| 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: | Whole Thread | Raw Message | 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 |