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.
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
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
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
...
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
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
[ 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
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
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,
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)
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]
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
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
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
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
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
16 matches
Mail list logo