Re: Hook for extensible parsing.

On Wed, Sep 15, 2021 at 02:25:17PM +0100, Simon Riggs wrote:
> On Sat, 1 May 2021 at 08:24, Julien Rouhaud <rjuju123(at)gmail(dot)com> wrote:
>
> > Being able to extend core parser has been requested multiple times, and AFAICT
> > all previous attempts were rejected not because this isn't wanted but because
> > the proposed implementations required plugins to reimplement all of the core
> > grammar with their own changes, as bison generated parsers aren't extensible.
> >
> > I'd like to propose an alternative approach, which is to allow multiple parsers
> > to coexist, and let third-party parsers optionally fallback on the core
> > parsers.
>
> Yes, that approach has been discussed by many people, most recently
> around the idea to create a fast-path grammar to make the most
> frequently used SQL parse faster.
>
> > 0002 implements a lame "sqlol" parser, based on LOLCODE syntax, with only the
> > ability to produce "select [col, ] col FROM table" parsetree, for testing
> > purpose. I chose it to ensure that everything works properly even with a
> > totally different grammar that has different keywords, which doesn't even ends
> > statements with a semicolon but a plain keyword.
>
> 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.
>
> What we need is something in core that actually makes use of this. The
> reason for that is not politics, but a simple test of whether the
> feature makes sense AND includes all required bells and whistles to be
> useful in the real world.
>
> Core doesn't need a LOL parser and I don't think we should commit that.

It doesn't, but it very likely needs something people can use when
they create a new table AM, and that we should use the hook in core to
implement the heap* table AM to make sure the thing is working at DDL
time.

> If we do this, I think it should have CREATE LANGUAGE support, so
> that each plugin can be seen as an in-core object and allow security
> around which users can execute which language types, allow us to
> switch between languages and have default languages for specific
> users or databases.

That's a great idea, but I must be missing something important as it
relates to parser hooks. Could you connect those a little more
explicitly?

Best,
David.

* It's not actually a heap in the sense that the term is normally used
in computing. I'd love to find out how it got to have this name and
document same so others aren't also left wondering.
--
David Fetter <david(at)fetter(dot)org> http://fetter.org/
Phone: +1 415 235 3778

Remember to vote!
Consider donating to Postgres: http://www.postgresql.org/about/donate