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 07:35:32
Message-ID: 3CBA82C4.6020504@wgops.com (view raw or flat)
Thread:
Lists: pgsql-hackerspgsql-patches

Tom Lane wrote:

>
>So far I think everyone agrees that if an explicit column name list is
>given, then it should fail if the column values don't match up.  But
>what do you think about the case with no column name list?
>
I'm on the fence in that situation.  Though I'd lean towards a patch 
thats a sort of compromise.  IIF the 'remaining' columns (IE columns 
unspecified) have some sort of default or auto-generated value (forgive 
me I'm just getting back into workign with postgresql) like a SERIAL or 
TIMESTAMP allow it, IFF any of them do not have a default value then 
fail.  This will make it 'do the right thing' -- it's not exactly what 
the spec does, but it's close to the current behavior that several 
others (including myself) see as beneficial in the case of interactive use.

As far as implementation of this sort of compromise, I'm not sure, but 
it hsould be possible, assuming the planner knows/flags triggers on 
column inserts and can make decisions and reject the query based on that 
information (I don't think that information would be in the parser)

>
>
>			regards, tom lane
>



In response to

Responses

pgsql-hackers by date

Next:From: Curt SampsonDate: 2002-04-15 07:41:19
Subject: Re: Importing Large Amounts of Data
Previous:From: Christopher Kings-LynneDate: 2002-04-15 07:06:00
Subject: Re: Importing Large Amounts of Data

pgsql-patches by date

Next:From: Tatsuo IshiiDate: 2002-04-15 07:50:23
Subject: Re: [PATCHES] unknownin/out patch (was PQescapeBytea is
Previous:From: Tom LaneDate: 2002-04-15 05:30:57
Subject: Re: Commands/ directory reorganisation

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