"Rod Taylor" <rbt@zort.ca> writes:
> CREATE TABLE tab(col1 text, col2 text);
> INSERT INTO tab (col1, col2) VALUES ('val1'); -- bad by spec (enforced
> by patch)
> INSERT INTO tab (col1, col2) VALUES ('val1', 'val2'); -- good
> INSERT INTO tab VALUES ('val1'); -- bad by spec (not enforced)
> INSERT INTO tab VALUES ('val1', 'val2'); -- good
> Currently in postgres all of the above are valid. I'd like to rule
> out the first case (as enforced by the patch) as it's obvious the user
> had intended to have two values.
Seems reasonable.
> For the latter one, it could be argued that the user understands the
> table in question and has inserted the values they require.
Ruling out this case would break a technique that I've used a lot in the
past, which is to put defaultable columns (eg, SERIAL columns) at the
end, so that they can simply be left out of quick manual inserts.
So I agree with this part too. (I wouldn't necessarily write
application code that way, but then I believe in the theory that robust
application code should always specify an explicit column list.)
For the record --- I actually am in favor of this patch; but I wanted
to see the change discussed and defended in a more widely-read mailing
list than -patches. If there are no objections from the assembled
hackers, apply away ...
regards, tom lane
