Re: Hook for extensible parsing.

From: Julien Rouhaud <rjuju123(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Jim Mlodgenski <jimmy76(at)gmail(dot)com>, Simon Riggs <simon(dot)riggs(at)enterprisedb(dot)com>, PostgreSQL Developers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Hook for extensible parsing.
Date: 2021-09-15 17:44:52
Message-ID: CAOBaU_aaXh7Ck+tuwyQAsJwSeMNmTC=+w9BvbfFYmR8RU-cuSQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, Sep 16, 2021 at 1:23 AM Julien Rouhaud <rjuju123(at)gmail(dot)com> wrote:
>
> On Thu, Sep 16, 2021 at 12:57 AM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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.

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Ranier Vilela 2021-09-15 18:27:00 Re: Getting ERROR "subplan "SubPlan 1" was not initialized" in EXISTS subplan when using for list partition.
Previous Message Pavel Stehule 2021-09-15 17:31:13 Re: proposal: possibility to read dumped table's name from file