Tom Lane writes:
> 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.
Oh, I really don't think I should modify the parameter list of such
*present* function. The comment on it looked very *proud* to me, proud,
because it's been highlighted that it doesn't play a role which stmt. is
comming in, so everything breaking this *pride* would be an evil hack,
wouldn't it?
Futhermore Bruce says, such small'n'easy hack must match everybody's
expectations before it gets a chance to be accepted ,)
Seriously: I know, it's not the finest method to change the grammar, though
it looks very compact to me.
Questions: I followed your recomendation to create a new parse-node for
DEFAULT. Is this step ok? I'll additionally take a look on what to do to
*fully* integrate a new node - Bruce said, maybe he would be able to help a
little. Further, if the previous step is correct then, do I understand you
right: you are not enjoyed of the rejecting DEFAULT in cases other than
INSERT, but should DEFAULT be recognized anyway, then translated to my new
parse-node "Default" (grammar ends here) and then handled in
transformTargetList? Or did you mean, that the grammer hasn't to be changed
at all and DEFAULT is to be handled out later from the string constant
(unknown type)?
I'll take a look on the call chain leading to the final call of
transormTargetList - maybe I'll find a way to avoid a modification of it's
parameter list. Is there a chance to handle Default somewhere *above*
transformTargetList without midifying it's parameters?
If no, then can I really feel free to modify this parameter list and adapt
it everywhere I find a call to this function?
*But*: What would you say, if I add a mitm-function called instead of
transformTargetList in the case of INSERT, doing a thing and finally calling
transformTargetList? Smth. like transformInsertTargetList? Wouldn't it be
more elegant than modifying the parameter list of one of the basic
transformation functions? Then, I could add a case to transformTargetList
where I would generate an error on every other Default-parse-node comming
in, denying it and explaining it's cause? Would it be ok?
rgds
Pavlo Baron