On Sat, 1 May 2021 at 08:24, Julien Rouhaud <rjuju...@gmail.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. 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. -- Simon Riggs http://www.EnterpriseDB.com/
