Tom, can you check to see if

  insert into <tablename> default values;

works on an unmodified current tree? I've got things ripped apart, but
I would have expected this to work, and am suspecting that it is a
problem introduced in your rewrite of this area a month or two ago.
(On a table without explicit default values, it should fill with
NULLs, but on my system I get an Assert failure because the target
list is never filled in.)

As usual, there is no coverage of this in the regression tests, so
there is no reason we should have caught this earlier... :(

                     - Thomas

-- 
Thomas Lockhart				lockhart@alumni.caltech.edu
South Pasadena, California

Sun, 19 Sep 1999 15:24:22 +0000
Thomas Lockhart <lockhart@alumni.caltech.edu>
INSERT/DEFAULT VALUES broken?
Thomas Lockhart <lockhart@alumni.caltech.edu> writes:
> Tom, can you check to see if
>   insert into <tablename> default values;

> works on an unmodified current tree? I've got things ripped apart, but
> I would have expected this to work, and am suspecting that it is a
> problem introduced in your rewrite of this area a month or two ago.

It bombs for me too, so I suspect you are right that I broke it when
I rearranged the analysis of INSERT.  It's probably a minor oversight
someplace in there.

Do you want me to fix it in current tree, or would it be wasted work
considering that you are busy doing major parser rearrangements
yourself?

			regards, tom lane

Sun, 19 Sep 1999 11:59:10 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Re: INSERT/DEFAULT VALUES broken? 
> > Tom, can you check to see if
> >   insert into <tablename> default values;
> > works on an unmodified current tree? I've got things ripped apart, but
> > I would have expected this to work, and am suspecting that it is a
> > problem introduced in your rewrite of this area a month or two ago.
> It bombs for me too, so I suspect you are right that I broke it when
> I rearranged the analysis of INSERT.  It's probably a minor oversight
> someplace in there.
> Do you want me to fix it in current tree, or would it be wasted work
> considering that you are busy doing major parser rearrangements
> yourself?

If it isn't too much trouble, it would be great if you could look at
it. I'd like to stay focused on the join syntax (for inner joins at
the moment), but need to regression test things like this to make sure
new stuff hasn't introduced breakage...

                     - Thomas

-- 
Thomas Lockhart				lockhart@alumni.caltech.edu
South Pasadena, California

Sun, 19 Sep 1999 16:26:18 +0000
Thomas Lockhart <lockhart@alumni.caltech.edu>
Re: INSERT/DEFAULT VALUES broken?
>>>> insert into <tablename> default values;

>> It bombs for me too, so I suspect you are right that I broke it when
>> I rearranged the analysis of INSERT.  It's probably a minor oversight
>> someplace in there.

Nope, not a parser problem at all; rewriter brain damage.  It's been
broken at least since 6.4, but only if you do INSERT ... DEFAULT VALUES
into a table that has no columns with default values, and only if you
have Asserts turned on (so the average user wouldn't see it anyway).
Fix is to dike out incorrect Assert...

			regards, tom lane

Sun, 19 Sep 1999 13:25:07 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Re: INSERT/DEFAULT VALUES broken? 
> >>>> insert into <tablename> default values;
> Nope, not a parser problem at all; rewriter brain damage.  It's been
> broken at least since 6.4, but only if you do INSERT ... DEFAULT VALUES
> into a table that has no columns with default values, and only if you
> have Asserts turned on (so the average user wouldn't see it anyway).
> Fix is to dike out incorrect Assert...

Sorry about that; I usually don't run with Assert enabled, so wouldn't
have caught it earlier. Thanks for looking into it.

                      - Thomas

-- 
Thomas Lockhart				lockhart@alumni.caltech.edu
South Pasadena, California

Mon, 20 Sep 1999 03:06:48 +0000
Thomas Lockhart <lockhart@alumni.caltech.edu>
Re: INSERT/DEFAULT VALUES broken?