Re: Hook for extensible parsing. - Mailing list pgsql-hackers

From Julien Rouhaud
Subject Re: Hook for extensible parsing.
Date
Msg-id CAOBaU_bMzGz8C-CE8gwg8Sc4ZdUfM+vpO1gbQpeUfWLRex5eFA@mail.gmail.com
Whole thread Raw
In response to Re: Hook for extensible parsing.  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Hook for extensible parsing.
List 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 by date:

Previous
From: Tom Lane
Date:
Subject: Re: Hook for extensible parsing.
Next
From: Pavel Stehule
Date:
Subject: Re: proposal: possibility to read dumped table's name from file