On Fri, Dec 8, 2023 at 2:19 AM Robert Haas <robertmhaas@gmail.com> wrote:
> On Wed, Dec 6, 2023 at 10:26 AM Alvaro Herrera <alvherre@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