| 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 |