Re: Parser Hook

From: Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>
To: Julien Rouhaud <rjuju123(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 18:02:39
Message-ID: CAFj8pRDfgtmOY0a-jw4XeEfxOSVmtSFJL+kkSwHr0svboSMKWA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

po 15. 3. 2021 v 18:54 odesílatel Julien Rouhaud <rjuju123(at)gmail(dot)com>
napsal:

> 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?
>

I think all necessary executor's hooks are available already. On the
executor level, I was able to do all what I wanted.

I miss just preparsing, and postparsing hooks.

Regards

Pavel

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Justin Pryzby 2021-03-15 18:09:18 Re: Different compression methods for FPI
Previous Message Mark Dilger 2021-03-15 17:56:50 Re: REINDEX backend filtering