Re: remaining sql/json patches

Поиск
Список
Период
Сортировка
От Robert Haas
Тема Re: remaining sql/json patches
Дата
Msg-id CA+Tgmob1_krTvJH6qgv148foraVAz853SRwayjD2UqNdd3Nnmg@mail.gmail.com
обсуждение исходный текст
Ответ на Re: remaining sql/json patches  (Alvaro Herrera <alvherre@alvh.no-ip.org>)
Ответы Re: remaining sql/json patches  (Amit Langote <amitlangote09@gmail.com>)
Список pgsql-hackers
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.

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



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Andres Freund
Дата:
Сообщение: Re: Remove MSVC scripts from the tree
Следующее
От: Andres Freund
Дата:
Сообщение: Re: Remove MSVC scripts from the tree