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 17:41:36 |
Message-ID: | CAFj8pRC8snHZA=xPk0mF3Y_g7RGOuef-GOc4GkNrb65AO7f-iQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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.
From | Date | Subject | |
---|---|---|---|
Next Message | Julien Rouhaud | 2021-03-15 17:50:44 | Re: REINDEX backend filtering |
Previous Message | Mark Dilger | 2021-03-15 17:40:25 | Re: REINDEX backend filtering |