Re: Hook for extensible parsing.
От | Julien Rouhaud |
---|---|
Тема | Re: Hook for extensible parsing. |
Дата | |
Msg-id | CAOBaU_aaXh7Ck+tuwyQAsJwSeMNmTC=+w9BvbfFYmR8RU-cuSQ@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Hook for extensible parsing. (Julien Rouhaud <rjuju123@gmail.com>) |
Список | pgsql-hackers |
On Thu, Sep 16, 2021 at 1:23 AM Julien Rouhaud <rjuju123@gmail.com> wrote: > > 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? Ah, now that I think more about it I think that you're talking about unqualified fields? I was naively assuming that those wouldn't be allowed by oracle, but I guess that wishful thinking.
В списке pgsql-hackers по дате отправления: