Re: Hook for extensible parsing. - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Hook for extensible parsing.
Date
Msg-id 984300.1631719616@sss.pgh.pa.us
Whole thread Raw
In response to Re: Hook for extensible parsing.  (Jim Mlodgenski <jimmy76@gmail.com>)
Responses Re: Hook for extensible parsing.
List pgsql-hackers
Jim Mlodgenski <jimmy76@gmail.com> writes:
> On Wed, Sep 15, 2021 at 9:25 AM Simon Riggs
> <simon.riggs@enterprisedb.com> wrote:
>> The general rule has always been that we don't just put hooks in, we
>> always require an in-core use for those hooks. I was reminded of that
>> myself recently.

> That's not historically what has happened. There are several hooks with
> no in core use such as emit_log_hook and ExplainOneQuery_hook.

Yeah.  I think the proper expectation is that there be a sufficiently
worked-out example to convince us that the proposed hooks have real-world
usefulness, and are not missing any basic requirements to make them do
something useful.  Whether the example ends up in our tree is a
case-by-case decision.

In the case at hand, what's troubling me is that I don't see any
particular use in merely substituting a new bison grammar, if it
still has to produce parse trees that the rest of the system will
understand.  Yeah, you could make some very simple surface-syntax
changes that way, but it doesn't seem like you could do anything
interesting (like, say, support Oracle-style outer join syntax).
AFAICS, to get to a useful feature, you'd then need to invent an
extensible Node system (which'd be hugely invasive if it's feasible
at all), and then probably more things on top of that.  So I'm not
convinced that you've demonstrated any real-world usefulness.

            regards, tom lane



pgsql-hackers by date:

Previous
From: Pavel Stehule
Date:
Subject: Re: Trigger position
Next
From: Tom Lane
Date:
Subject: Re: EXPLAIN(VERBOSE) to CTE with SEARCH BREADTH FIRST fails