Delaying insertion of default values

If you have a default value for a column, say

create table t (a int4, b int4 default 12345);

and you write a command that depends on the default, say

insert into t (a) values (1);

the way that the default is currently accounted for is that the parser
rewrites the command into

insert into t (a,b) values (1, 12345);

(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
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
rule mechanism. Unless I hear objections, I will do that while I am
cleaning up INSERT processing for the INSERT ... SELECT ... GROUP BY bug.

More generally, I wonder whether it is such a good idea for rules to be
stored as parsetrees. For example, I can't drop and recreate a table
mentioned in a rule attached to a different table, because the compiled
rule includes the OIDs of the tables it references. So the compiled
rule will start failing if I do that. (Right now, this causes a core
dump :-( ... apparently someone is assuming that the OID in an RTE will
never be bad ...)

With rules stored as parsetrees, we need to be very careful about how
much semantic knowledge gets factored into the parsetree before it is
frozen as a rule. (This is another reason for pushing "optimization"
transformations out of the parser and into modules downstream of the
rule rewriter, BTW.)

Comments? Storing rules as plain text would be too slow, perhaps,
but would it help any to store rules as "raw" parsetrees that haven't
yet gone through analyze.c?

regards, tom lane