| 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:18:57 |
| Message-ID: | 20210315171857.nolveu7ezt2yceya@nol |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
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.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Julien Rouhaud | 2021-03-15 17:34:01 | Re: REINDEX backend filtering |
| Previous Message | Mark Dilger | 2021-03-15 17:13:55 | Re: REINDEX backend filtering |