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
