Re: [HACKERS] Delaying insertion of default values

Tom Lane wrote:
> 
> (this happens in transformInsertStmt()).  It strikes me that doing this
> in the parser is too early, and it needs to be done later, like after
> the rewriter.  Why?  Because the rule mechanism stores rules as
> parsetrees.  If the above INSERT is part of a rule, then the stored form
> of the rule will look like the rewritten command, with the default
> already attached.  This is bad: if I later alter the default for t.b,
> the rule won't get updated.
> 
> (I can't currently change the default with ALTER TABLE, I think, but
> sooner or later ALTER TABLE will be fixed.  I *can* alter t.b's default

ALTER TABLE could (or should?) re-compile table' rules...

> by dumping the database, changing the CREATE TABLE command for t, and
> reloading --- but the rule still won't be updated, because what's dumped
> out for it will look like "insert into t values (1, 12345);" !  Try it
> and see...)
> 
> I am inclined to think that attachment of default values should happen
> in the planner, at the same time that the targetlist is reordered to
> match the physical column order and dummy NULLs are inserted for missing
> columns (ie, expand_targetlist()).  Certainly it must happen after the

Why not? Not bad way, imho.

> rule mechanism.  Unless I hear objections, I will do that while I am
> cleaning up INSERT processing for the INSERT ... SELECT ... GROUP BY bug.

No objections -:).

Vadim