...
> 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
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
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
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 statin
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 the
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
> > 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 tha
"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)
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
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 be
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 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 (c
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,
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'
[ 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 adeq
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 INTO
16 matches
Mail list logo
