On Wed, Sep 15, 2021 at 9:25 AM Simon Riggs <simon.ri...@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. The recent openssl_tls_init_hook only has a usage in src/test/modules
> 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. > Agreed. There should be something in src/test/modules to exercise this but probably more to flush things out. Maybe extending adminpack to use this so if enabled, it can use syntax like: FILE READ 'foo.txt' > Core doesn't need a LOL parser and I don't think we should commit that. > +1 > 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. > This hook allows extension developers to supplement syntax in addition to adding a whole new language allowing the extension to appear more native to the end user. For example, pglogical could use this to add syntax to do a CREATE NODE instead of calling the function create_node. Adding CREATE LANGUAGE support around this would just be for a narrow set of use cases where a new language is added.
