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
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers pgsql-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

Browse pgsql-hackers by date

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

Browse pgsql-patches by date

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