po 15. 3. 2021 v 18:54 odesÃlatel Julien Rouhaud <rjuju...@gmail.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 <rjuju...@gmail.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
