Re: TODO question
От | Pavlo Baron |
---|---|
Тема | Re: TODO question |
Дата | |
Msg-id | 012301c190b5$1cd50f50$6500a8c0@bw1 обсуждение исходный текст |
Ответ на | Re: TODO question (Bruce Momjian <pgman@candle.pha.pa.us>) |
Список | pgsql-hackers |
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
В списке pgsql-hackers по дате отправления: