Thread: a quick question

a quick question

From
"scott.marlowe"
Date:
Hey, me and a few other folks were having a discussion off list, and the 
subject of inserts and missing columns came up. you may remember the point 
in the "I'm done" post by Bruce.  It said:

> o -Disallow missing columns in INSERT ... VALUES, per ANSI
> > What is this, and why is it marked done?

We used to allow INSERT INTO tab VALUES (...) to skip the trailing
columns and automatically fill in null's.  That is fixed, per ANSI.


Anyway, I just tested it on 7.3b1 and I can still do an insert with the 
columns missing and it fills in defaults or nulls, with defaults being the 
preference.

So, are we gonna make postgresql throw an error when someone tries to 
submit an insert with too few columns to match up to the implicit column 
list, or not?

This just seems like a change designed to piss off users to me, but I can 
see where it does encourage better query crafting.



Re: a quick question

From
Rod Taylor
Date:
On Tue, 2002-09-17 at 16:44, scott.marlowe wrote:
> Hey, me and a few other folks were having a discussion off list, and the 
> subject of inserts and missing columns came up. you may remember the point 
> in the "I'm done" post by Bruce.  It said:
> 
> > o -Disallow missing columns in INSERT ... VALUES, per ANSI
> > > What is this, and why is it marked done?
> 
> We used to allow INSERT INTO tab VALUES (...) to skip the trailing
> columns and automatically fill in null's.  That is fixed, per ANSI.
> 
> So, are we gonna make postgresql throw an error when someone tries to 
> submit an insert with too few columns to match up to the implicit column 
> list, or not?

There was a vote to keep previous behaviour when the column list wasn't
supplied, so it's not to ANSI spec, it's to our improved version ;)

INSERT INTO (...) VALUES (...) will not allow you to skip value entries,
but the keyword DEFAULT is available now, so it shouldn't be much of an
issue.

--  Rod Taylor