Re: [HACKERS] parser enhancement request for 6.5
От | Thomas Lockhart |
---|---|
Тема | Re: [HACKERS] parser enhancement request for 6.5 |
Дата | |
Msg-id | 3736F2E0.F667890D@alumni.caltech.edu обсуждение исходный текст |
Ответ на | Re: [HACKERS] parser enhancement request for 6.5 (Bruce Momjian <maillist@candle.pha.pa.us>) |
Ответы |
Re: [HACKERS] parser enhancement request for 6.5
|
Список | pgsql-hackers |
> > I would like for you to also consider adding the following to gram.y for > > version 6.5: > > | NULL_P '=' a_expr > > { $$ = makeA_Expr(ISNULL, NULL, $3, NULL); } > > I know there was some discussion about this earlier including comments > > against this. Access 97 is now generating the following statement and > > error... I'm not certain that this patch should survive. There are at least two other places in the parser which should be modified for symmetry (the "b_expr" and the default expressions) and I recall that these lead to more shift/reduce conflicts. Remember that shift/reduce conflicts indicate that some portion of the parser logic can *never* be reached, which means that some feature (perhaps the new one, or perhaps an existing one) is disabled. There is currently a single shift/reduce conflict in gram.y, and I'm suprised to find that it is *not* due to the "NULL_P '=' a_expr" line. I'm planning on touching gram.y to hunt down the shift/reduce conflict (from previous work I think it in Stefan's "parens around selects" mods), and I'll look at the NULL_P issue again also. I'll reiterate something which everyone probably knows: "where NULL = expr" is *not* standard SQL92, and any company selling products which implement this rather than the standard "where expr is NULL" should make your "don't buy" list, rather than your "only buy" list, which is what they are trying to force you to do :( - Tom -- Thomas Lockhart lockhart@alumni.caltech.edu South Pasadena, California
В списке pgsql-hackers по дате отправления: