Re: Parser Hook

From: Julien Rouhaud <rjuju123(at)gmail(dot)com>
To: Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>
Cc: Jim Mlodgenski <jimmy76(at)gmail(dot)com>, Andres Freund <andres(at)anarazel(dot)de>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Parser Hook
Date: 2021-03-15 17:54:47
Message-ID: 20210315175447.6mpq6nnfmkr34l2n@nol
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Mon, Mar 15, 2021 at 06:41:36PM +0100, Pavel Stehule wrote:
> po 15. 3. 2021 v 18:18 odesílatel Julien Rouhaud <rjuju123(at)gmail(dot)com>
> napsal:
>
> > On Mon, Mar 15, 2021 at 06:05:52PM +0100, Pavel Stehule wrote:
> > >
> > > Possibility to work with a parser is one main reason for forking
> > postgres.
> > > Lot of interestings projects fail on the cost of maintaining their own
> > fork.
> > >
> > > Maybe a good enough possibility is the possibility to inject an own
> > parser
> > > called before Postgres parser. Then it can do a transformation from
> > "CREATE
> > > PIPE ..." to "SELECT extparse("CREATE PIPE()". There can be a switch if
> > > returned content is string for reparsing or already prepared AST.
> >
> > Having a hook that returns a reformatted query string would definitely be
> > easier to write compared to generating an AST, but the overhead of parsing
> > the
> > query twice plus deparsing it will probably make that approach way too
> > expensive in many usecases, so we shouldn't go that way.
> >
>
> yes - so it can be nice to have more possibilities.
>
> parsing is expensive - but on today computers, the cost of parsing is low -
> the optimization is significantly more expensive.
>
> I wrote some patches in this area (all rejected by Tom :)), and a lot of
> work can be done after parser and before the analysis stage. Probably, the
> parser hook is not good enough, there should be an analysis stage hook too.

If you need an parse/analyse hook, it means that you're extending the AST, so
you probably also need executor support for that right? Or is it only to
support syntactic sugar in the analysis rather than parsing?

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Mark Dilger 2021-03-15 17:56:50 Re: REINDEX backend filtering
Previous Message Julien Rouhaud 2021-03-15 17:50:44 Re: REINDEX backend filtering