Re: TODO question

"Pavlo Baron" <pb@pbit.org> writes:
> Tom Lane writes:
>> 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.

> Why transformTargetList? The comment above this function says that it's
> indiffernet if there is a SELECT or INSERT or an other stmt. being parsed -
> the expressions are just to be transformed? Woudn't it break this
> indifference if I add a new branch handling with the Default node to this
> function?

Well, you could either assume that a DEFAULT node must be okay if
present (relying on the grammar to have allowed it only for INSERT),
or you could add a parameter to transformTargetList saying whether it's
dealing with an INSERT list or not.  If not, it could error out if it
sees a DEFAULT node.  This might be better than rejecting DEFAULT in
the grammar, since you could give a more specific error message than
just "parse error"; and you wouldn't need two separate targetlist
constructs in the grammar.

You also need to think about what to return in the output targetlist if
you see a DEFAULT node.  You can't build a correct, valid Resdom since
you have no info about datatype.  I think I'd be inclined to return the
DEFAULT node in place of a TargetEntry, and then transformInsertStmt
would be changed to discard list items that weren't TargetEntrys.  A
little ugly, but probably less ugly than building a not-really-valid
TargetEntry structure.
        regards, tom lane