Skip site navigation (1) Skip section navigation (2)

Re: ANSI Compliant Inserts

From: Michael Loftis <mloftis(at)wgops(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>, Rod Taylor <rbt(at)zort(dot)ca>,pgsql-patches(at)postgresql(dot)org
Subject: Re: ANSI Compliant Inserts
Date: 2002-04-15 14:33:20
Message-ID: 3CBAE4B0.7030308@wgops.com (view raw or flat)
Thread:
Lists: pgsql-hackerspgsql-patches

Tom Lane wrote:

>Michael Loftis <mloftis(at)wgops(dot)com> writes:
>
>>\<snip snip -- no I'm not ignoring anything just cutting down on quoting>
>>
>
>
>Now consider same scenario except I write the rule's INSERT without
>an explicit column list.  If we follow the letter of the spec, the
>rule will now fail.  How is this sensible or consistent behavior?
>The case that should be laxer/easier is being treated *more* rigidly.
>
>In any case, the above comparison shows that it's not very consistent
>to require explicit defaults to be available for the omitted column(s).
>INSERT with an explicit column list does not have any such requirement.
>
>			regards, tom lane
>
In the case of an implicit response it's to be treated as if all columns 
had been specified (according to the spec).  Which is why the spec says 
that if you miss a column it's a bad INSERT unless you have specified 
only a subset.

Unless I'm misreading (which I could be)

Either way, as I said I'm not wholly in favor of either way because both 
solutions to me make equal sense, but keepign the ability to 'assume' 
default values (whether it's NULL or derived) is the better one in this 
case, if the race condition is indeed an issue.

BTW tom, I can't send mail directly to you -- 
black-holes.five-ten-sg.com (or something like that) lists most of 
Speakeasy's netblocks (As well as the rest of the world heh) as 
'dialups' and such.  It's a liiittle over-paranoid to drop mail based on 
their listings, but just wanted to letcha know you are losing some 
legitimate mail :)  No biggie though I just post ot the list anyway so 
you get it still ;)

Michael


In response to

pgsql-hackers by date

Next:From: Mario WeilguniDate: 2002-04-15 14:46:41
Subject: Re: Inefficient handling of LO-restore + Patch
Previous:From: Tom LaneDate: 2002-04-15 14:32:10
Subject: Re: Inefficient handling of LO-restore + Patch

pgsql-patches by date

Next:From: Rod TaylorDate: 2002-04-15 14:56:25
Subject: Doc fix for INSERT ... (DEFAULT, ...)
Previous:From: Tom LaneDate: 2002-04-15 14:08:55
Subject: Re: ANSI Compliant Inserts

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group