Re: Parser Hook

From: Andres Freund <andres(at)anarazel(dot)de>
To: Jim Mlodgenski <jimmy76(at)gmail(dot)com>
Cc: PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Parser Hook
Date: 2021-02-22 20:52:42
Message-ID: 20210222205242.ygbalnec6pq2tzdp@alap3.anarazel.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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

In response to

  • Parser Hook at 2021-02-22 16:20:54 from Jim Mlodgenski

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Andres Freund 2021-02-22 21:21:58 Re: libpq compression
Previous Message Tom Lane 2021-02-22 20:44:30 Re: libpq compression