Re: TODO question

Tom Lane writes:

> 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 during
> planning, not during parse analysis. This keeps stored rules from
> prematurely absorbing default information, which is necessary for
> ALTER TABLE SET DEFAULT to work unsurprisingly with rules. See
> pgsql-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.

this is an information of gold! I was really unhappy with my hacks looked
like an alien element to me (and surely being those, too). When I look on
the pointer chain I used to get the default value... And I'm not sure if my
solution would handle every kind of default expr. correctly.

>
> 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.

I see. Can I say in simple words, that everything that can be parsed without
any knowledge about the database condition has to be pre-parse-analized and
the rest has to be post-parse-analized, then? Or, things needed to parse
correctly are prepared by the pre-parser-analysis? Could you point me to a
summary (if any) where I would find a rough desc. on such distinction?
I'll re-code to match the basic concepts you've explained here.

BTW, what about constructs like:

INSERT INTO foo VALUES (1,,2);

wouldn't it make the whole thing a bit simpler? or:

INSERT INTO foo(c1, c2, c3) VALUES (,1,);

I find, this short form is a bit more finger-freiendly and I think, it could
be implemented without dropping the standard one? This would better match
your idea about "to omit" the DEFAULT-ed column, since one doesn't care of
what value has to be put in if you write smth. like "...VALUES
(,,,,,4,,,1,)". Or, there could be an expression defined if not even DEFAULT
has been specified, an other expression than the DEFAULT expr., eg, (I just
spin around :-) ) it could be allowed to define smth. like OMITED appearing
as a place holder for a post-parse replacement where eg column references
could be used, eg:

db=# CREATE TABLE foo (c1 int2, c2 int2, c3 int2 OMITED c1*20, c4 int2);
db=# INSERT INTO foo values (2, 3,, 4);
db=# SELECT c3 FROM foo;
c3
----
40
(1 rows)

rgds
Pavlo Baron