Re: [HACKERS] [PATCHES] ANSI Compliant Inserts

2002-04-15 Thread Vince Vielhaber
On Mon, 15 Apr 2002, Tom Lane wrote: Peter Eisentraut [EMAIL PROTECTED] writes: I recall that this was the behavior we agreed we wanted. IMHO, it would be conditional on the INSERT ... VALUES (DEFAULT) capability being provided. I'm not sure if that is there yet. That is there now.

Re: [HACKERS] [PATCHES] ANSI Compliant Inserts

2002-04-15 Thread Bruce Momjian
Peter Eisentraut wrote: Bruce Momjian writes: Peter, are you saying you don't want to require all columns to be specified when INSERT doesn't list the columns? Yes, that's what I'm saying. Too much breakage and annoyance potential in that change. OK, how about a NOTICE stating that

Re: [HACKERS] [PATCHES] ANSI Compliant Inserts

2002-04-15 Thread Bruce Momjian
Vince Vielhaber wrote: On Mon, 15 Apr 2002, Tom Lane wrote: Peter Eisentraut [EMAIL PROTECTED] writes: I recall that this was the behavior we agreed we wanted. IMHO, it would be conditional on the INSERT ... VALUES (DEFAULT) capability being provided. I'm not sure if that is there

Re: [HACKERS] [PATCHES] ANSI Compliant Inserts

2002-04-15 Thread Peter Eisentraut
Bruce Momjian writes: OK, how about a NOTICE stating that the missing columns were filled in with defaults? Please not. -- Peter Eisentraut [EMAIL PROTECTED] ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster

Re: [HACKERS] [PATCHES] ANSI Compliant Inserts

2002-04-15 Thread Thomas Lockhart
... OK, how about a NOTICE stating that the missing columns were filled in with defaults? Yuck. There is a short path from that to rejecting the insert, but printing the entire insert statement which would have been acceptable in the error message ;) - Thomas

Re: [HACKERS] [PATCHES] ANSI Compliant Inserts

2002-04-14 Thread Rod Taylor
I submitted a patch which would make Postgresql ANSI compliant in regards to INSERT with a provided column list. As Tom states below, this is not full compliance. CREATE TABLE tab(col1 text, col2 text); INSERT INTO tab (col1, col2) VALUES ('val1'); -- bad by spec (enforced by patch) INSERT

Re: [HACKERS] [PATCHES] ANSI Compliant Inserts

2002-04-14 Thread Bruce Momjian
[ Discussion moved to hackers.] We are discussing TODO item: o Disallow missing columns in INSERT ... VALUES, per ANSI Tom Lane wrote: Bruce Momjian [EMAIL PROTECTED] writes: Do you want to argue we should continue allowing it? No; I'm objecting that there hasn't been adequate

Re: [HACKERS] [PATCHES] ANSI Compliant Inserts

2002-04-14 Thread Bruce Momjian
Tom Lane wrote: 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

Re: [HACKERS] [PATCHES] ANSI Compliant Inserts

2002-04-14 Thread Bruce Momjian
Rod Taylor wrote: For the latter one, it could be argued that the user understands the table in question and has inserted the values they require. New columns are added at the end, and probably don't affect the operation in question so why should it be changed to suit new columns? But,

Re: [HACKERS] [PATCHES] ANSI Compliant Inserts

2002-04-14 Thread Bruce Momjian
Peter Eisentraut wrote: Rod Taylor writes: I submitted a patch which would make Postgresql ANSI compliant in regards to INSERT with a provided column list. As Tom states below, this is not full compliance. CREATE TABLE tab(col1 text, col2 text); INSERT INTO tab (col1, col2)

Re: [HACKERS] [PATCHES] ANSI Compliant Inserts

2002-04-14 Thread Peter Eisentraut
Bruce Momjian writes: Peter, are you saying you don't want to require all columns to be specified when INSERT doesn't list the columns? Yes, that's what I'm saying. Too much breakage and annoyance potential in that change. -- Peter Eisentraut [EMAIL PROTECTED]

Re: [HACKERS] [PATCHES] ANSI Compliant Inserts

2002-04-14 Thread Tom Lane
Peter Eisentraut [EMAIL PROTECTED] writes: I recall that this was the behavior we agreed we wanted. IMHO, it would be conditional on the INSERT ... VALUES (DEFAULT) capability being provided. I'm not sure if that is there yet. That is there now. Do you recall when this was discussed

Re: [HACKERS] [PATCHES] ANSI Compliant Inserts

2002-04-14 Thread Tom Lane
Bruce Momjian [EMAIL PROTECTED] writes: Tom Lane wrote: 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. Yes, I understand the

Re: [HACKERS] [PATCHES] ANSI Compliant Inserts

2002-04-14 Thread Tom Lane
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

Re: [HACKERS] [PATCHES] ANSI Compliant Inserts

2002-04-14 Thread Rod Taylor
INSERT INTO tab VALUES ('val1'); -- bad by spec (not enforced) INSERT INTO tab VALUES ('val1', 'val2'); -- good I recall that this was the behavior we agreed we wanted. IMHO, it would be conditional on the INSERT ... VALUES (DEFAULT) capability being provided. I'm not sure if that is

Re: [HACKERS] [PATCHES] ANSI Compliant Inserts

2002-04-14 Thread Peter Eisentraut
Rod Taylor writes: I submitted a patch which would make Postgresql ANSI compliant in regards to INSERT with a provided column list. As Tom states below, this is not full compliance. CREATE TABLE tab(col1 text, col2 text); INSERT INTO tab (col1, col2) VALUES ('val1'); -- bad by spec