Re: remaining sql/json patches

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>
Cc: Amit Langote <amitlangote09(at)gmail(dot)com>, jian he <jian(dot)universality(at)gmail(dot)com>, Andres Freund <andres(at)anarazel(dot)de>, Andrew Dunstan <andrew(at)dunslane(dot)net>, Erik Rijkers <er(at)xs4all(dot)nl>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: remaining sql/json patches
Date: 2023-12-07 17:19:24
Message-ID: CA+Tgmob1_krTvJH6qgv148foraVAz853SRwayjD2UqNdd3Nnmg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, Dec 6, 2023 at 10:26 AM Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)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.

--
Robert Haas
EDB: http://www.enterprisedb.com

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Andrey Borodin 2023-12-07 17:32:20 Re: Proposal to add page headers to SLRU pages
Previous Message Andres Freund 2023-12-07 17:05:13 Re: Remove MSVC scripts from the tree