"Rod Taylor" <[EMAIL PROTECTED]> 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 ---------------------------(end of broadcast)--------------------------- TIP 6: Have you searched our list archives? http://archives.postgresql.org