On Fri, Dec 8, 2023 at 2:19 AM Robert Haas <robertmh...@gmail.com> wrote: > On Wed, Dec 6, 2023 at 10:26 AM Alvaro Herrera <alvhe...@alvh.no-ip.org> > wrote: > > > I think I'm inclined toward adapting the LA-token fix (attached 0005), > > > because we've done that before with SQL/JSON constructors patch. > > > Also, if I understand the concerns that Tom mentioned at [1] > > > correctly, maybe we'd be better off not assigning precedence to > > > symbols as much as possible, so there's that too against the approach > > > #1. > > > > Sounds ok to me, but I'm happy for this decision to be overridden by > > others with more experience in parser code. > > In my experience, the lookahead solution is typically suitable when > the keywords involved aren't used very much in other parts of the > grammar. I think the situation that basically gets you into trouble is > if there's some way to have a situation where NESTED shouldn't be > changed to NESTED_LA when PATH immediately follows. For example, if > NESTED could be used like DISTINCT in a SELECT query: > > SELECT DISTINCT a, b, c FROM whatever > > ...then that would be a strong indication in my mind that we shouldn't > use the lookahead solution, because what if you substitute "path" for > "a"? Now you have a mess. > > I haven't gone over the grammar changes in a lot of detail so I'm not > sure how much risk there is here. It looks to me like there's some > syntax that goes NESTED [PATH] 'literal string', and if that were the > only use of NESTED or PATH then I think we'd be completely fine. I see > that PATH b_expr also gets added to xmltable_column_option_el, and > that's a little more worrying, because you don't really want to see > keywords that are used for special lookahead rules in places where > they can creep into general expressions, but it seems like it might > still be OK as long as NESTED doesn't also start to get used in other > places. If you ever create a situation where NESTED can bump up > against PATH without wanting that to turn into NESTED_LA PATH, then I > think it's likely that this whole approach will unravel. As long as we > don't think that will ever happen, I think it's probably OK. If we do > think it's going to happen, then we should probably grit our teeth and > use precedence.
Would it be messy to replace the lookahead approach by whatever's suiable *in the future* when it becomes necessary to do so? -- Thanks, Amit Langote EDB: http://www.enterprisedb.com