Parser Hook

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

Parser Hook

Jim Mlodgenski-2
As Jan mentioned in his thread about a pluggable wire protocol [0], AWS is working on a set of extensions for Babelfish. The intention is to not necessarily have it as a single monolithic extension, but be possible for people to use pieces of it as they need when they are migrating to PostgreSQL. Some may just need the functions or data types. Others may need the stored procedure language. Many times when enterprises are migrating databases, they have satellite applications that they may not be able to change or they are on a different schedules than the main application so the database still needs to support some of the old syntax. A common need in these situations is the parser.

Attached is a patch to place a hook at the top of the parser to allow for a pluggable parser. It is modeled after the planner_hook [1]. To test the hook, I have also attached a simple proof of concept that wraps the parser in a TRY/CATCH block to catch any parse errors. That could potentially help a class of users who are sensitive to parse errors ending up in the logs and leaking PII data or passwords.

-- Jim  
-- Amazon Web Services

[0] - https://www.postgresql.org/message-id/flat/CAGBW59d5SjLyJLt-jwNv%2BoP6esbD8SCB%3D%3D%3D11WVe5%3DdOHLQ5wQ%40mail.gmail.com
[1] - https://www.postgresql.org/message-id/flat/27516.1180053940%40sss.pgh.pa.us 

parser_hook.patch (2K) Download Attachment
quiet_parser.c (930 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Parser Hook

Andres Freund
Hi,

On 2021-02-22 11:20:54 -0500, Jim Mlodgenski wrote:

> As Jan mentioned in his thread about a pluggable wire protocol [0], AWS is
> working on a set of extensions for Babelfish. The intention is to not
> necessarily have it as a single monolithic extension, but be possible for
> people to use pieces of it as they need when they are migrating to
> PostgreSQL. Some may just need the functions or data types. Others may need
> the stored procedure language. Many times when enterprises are migrating
> databases, they have satellite applications that they may not be able to
> change or they are on a different schedules than the main application so
> the database still needs to support some of the old syntax. A common need
> in these situations is the parser.
>
> Attached is a patch to place a hook at the top of the parser to allow for a
> pluggable parser. It is modeled after the planner_hook [1]. To test the
> hook, I have also attached a simple proof of concept that wraps the parser
> in a TRY/CATCH block to catch any parse errors. That could potentially help
> a class of users who are sensitive to parse errors ending up in the logs
> and leaking PII data or passwords.

I don't think these are really comparable. In case of the planner hook
you can reuse the normal planner pieces, and just deal with the one part
you need to extend. But we have pretty much no infrastructure to use the
parser in a piecemeal fashion (there's a tiny bit for plpgsql).

Which in turn means that to effectively use the proposed hook to
*extend* what postgres accepts, you need to copy the existing parser,
and hack in your extensions. Which in turn invariably will lead to
complaints about parser changes / breakages the community will get
complaints about in minor releases etc.

I think the cost incurred for providing a hook that only allows
extensions to replace the parser with a modified copy of ours will be
higher than the gain.  Note that I'm not saying that I'm against
extending the parser, or hooks - just that I don't think just adding the
hook is a step worth doing on its own.

Imo a functional approach would really need to do the work to allow to
extend & reuse the parser in a piecemeal fashion and *then* add a hook.

Greetings,

Andres Freund