BTW, inserting the actual default expression in the parser is no good.
We just finished getting rid of that behavior last month:
2001-11-02 15:23 tgl
* src/backend/: catalog/heap.c, optimizer/prep/preptlist.c,parser/analyze.c: Add default expressions to INSERTs
duringplanning,not during parse analysis. This keeps stored rules fromprematurely absorbing default information, which
isnecessary forALTER TABLE SET DEFAULT to work unsurprisingly with rules. Seepgsql-bugs discussion 24-Oct-01.
The way I would tackle this is to do the work in
transformInsertStmt: if you find a Default node in the input targetlist,
you can simply omit the corresponding entry of the column list. In
other words, transform
INSERT INTO foo (col1, col2, col3) VALUES (11, DEFAULT, 13);
into
INSERT INTO foo (col1, col3) VALUES (11, 13);
Then you can rely on the planner to insert the correct defaults at planning
time.
My inclination would be to twiddle the order of operations so that the
Default node is spotted and intercepted before being fed to
transformExpr. This would probably mean doing some surgery on
transformTargetList. The advantage of doing it that way is that
transformExpr and subsequent processing need never see Default nodes
and can just error out if they do. The way you have it, Default needs
to pass through transformExpr, which raises a bunch of questions in my
mind about what parts of the system will need to accept it. There's
an established distinction between "pre-parse-analysis" node types
(eg, Attr) and "post-parse-analysis" node types (eg, Var), and we
understand which places need to support which node types as long as
that's the distinction. If you allow Default to pass through
transformExpr then you're to some extent allowing it to be a
post-parse-analysis node type, which doesn't strike me as a good idea.
regards, tom lane
