Re: Hook for extensible parsing.

Поиск
Список
Период
Сортировка
От Julien Rouhaud
Тема Re: Hook for extensible parsing.
Дата
Msg-id CAOBaU_bMzGz8C-CE8gwg8Sc4ZdUfM+vpO1gbQpeUfWLRex5eFA@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Hook for extensible parsing.  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: Hook for extensible parsing.  (Julien Rouhaud <rjuju123@gmail.com>)
Список pgsql-hackers
On Thu, Sep 16, 2021 at 12:57 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:
>
> > The requirement is that the parser can't leak any
> > node that the rest of the system doesn't know about, but you can do
> > what you want inside the parser.
>
> That's not what the patch actually does, though.  It only replaces
> the grammar, not semantic analysis.  So you couldn't associate the
> (+)-decorated WHERE clause with the appropriate join.  (And no,
> I will not accept that it's okay to perform catalog lookups in
> the grammar to get around that.  See comment at the head of gram.y.)

I never said that one should do catalog lookup for that?  What I said
is that you can do a specific semantic analysis pass in the hook if
you know that you can have extensible nodes in your parsetree, and you
can do that with that hook unless I'm missing something?

Yes that's not ideal, but I don't see how it can be worse than writing
some middleware that parses the query, rewrite it to postgres style
sql on the fly so that postgres can parse it again.  I'm also not sure
how the semantic analysis could be made generally extensible, if
possible at all, so that's the best I can propose.

If that approach is a deal breaker then fine I can accept it.



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

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: Hook for extensible parsing.
Следующее
От: Pavel Stehule
Дата:
Сообщение: Re: proposal: possibility to read dumped table's name from file