"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