Re: New Feature Request

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Michael Paquier <michael(at)paquier(dot)xyz>
Cc: Bruce Momjian <bruce(at)momjian(dot)us>, Bert Scalzo <bertscalzo2(at)gmail(dot)com>, pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Re: New Feature Request
Date: 2020-05-26 02:02:18
Message-ID: 20958.1590458538@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Michael Paquier <michael(at)paquier(dot)xyz> writes:
> On Mon, May 25, 2020 at 09:21:26PM -0400, Bruce Momjian wrote:
>> I think your best bet is to try getting someone to write a hook
>> that will do the replacement so that you don't need to modify too much
>> of the Postgres core code. You will need to have the hook updated for
>> new versions of Postgres, which adds to the complexity.

> Couldn't one just use the existing planner hook for that?

Yeah, probably. One could also make a case for creating a similar
hook for the rewriter so that a new parsetree could be substituted
before the rewrite step ... but it's really not clear whether it's
better to try to match the parsetree before or after rewriting.
I'd be inclined to just make use of the existing hook until there's
a pretty solid argument why we need another one.

Note to OP: the lack of response to your previous post seems to me
to indicate that there's little enthusiasm for having such a feature
in core Postgres. Thus, everybody is focusing on what sort of hooks
would be needed in-core to let an extension implement the feature.
Getting someone to write such an extension is left as an exercise
for the reader.

regards, tom lane

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Bruce Momjian 2020-05-26 02:03:43 Re: what can go in root.crt ?
Previous Message Bruce Momjian 2020-05-26 01:55:12 Re: Just for fun: Postgres 20?