Dependency-dependant extension augmentation

[yrashk]

Hey fellow @pgedc/members,

Wanted to explore something with you. I am building a constellation of extensions that know how to work with each other, but they are not always supposed to be strictly dependent. For example, I am building an authentication extension and I want to provide some building blocks for using it from HTTP endpoints facilitates by our HTTP server extension.

But naturally, I don't want the authentication extension to require the HTTP server.

I was thinking how should I approach it? One obvious answer is to create another extension (auth_httpd) that would require both auth and httpd extensions and provide whatever it is supposed to provide. Fine, but gets unwieldy and combinatorial :)

Another idea that I've worked with and seemed to have delivered good experience was to install event triggers and watch for the extension in question (such as httpd) to be installed and provision dependent parts upon creating this extension – while establishing a dependency for the cleanup. I was thinking of even generalizing this so that multiple extensions can easily reuse it without installing individual event triggers.

What do you think? How would you approach this?

[andreasscherbaum]

How do you plan to maintain the event trigger. Doesn't it come done to provide something similar to auth_http, which only provides the event trigger and the dependencies? Otherwise I don't see how you maintain these items separately and still make sure that they play well together.

[yrashk]

@andreasscherbaum, I am not sure what you mean. Can you elaborate?

I am inclined to generalize the problem over a singular event trigger that is called upon the creation of an extension that finds all functions adhering to specific naming/signature (let's say when_extension_available(name)) and calls them for every newly installed extension.

[andreasscherbaum]

Comes down to: where do you supply/store the configuration for the event trigger. Is this yet another extension?

[yrashk]

In the extensions themselves. As mentioned above, for example, by providing functions conforming to a certain naming and signature pattern.

[einhverfr]

So first it seems that the auth extension never should require the HTTP extension. The HTTP extension should be able to use the auth extension though. An important side question is whether the presence of the shared libraries should allow the HTTP extension to use the auth functions or not. That's a small technical detail and doesn't affect strategy but rather mechanism. This may matter though based on the scope of the service (is it per database? For the whole cluster? For the whole server?)

My view is that the best way to handle this is with a runtime check on HTTP server startup and/or triggered by a reload etc. I assume at the moment that this is a custom background worker (and that it doesn't listen on port 80 on *nix and so doesn't need root privileges). I would then allocate a memory context as a child of TopMemoryContext for runtime checks and configuration. Then I would make whatever runtime checks I wanted to do on startup and save the results there, You could also reserve, for example, SIGHUP to rerun these checks.

Another option would be to have a list of runtime config options for the HTTP service where a trigger would check for relevant extensions on configuration. An important problem here is that dropping the extension after configuring may have unexpected effects. So you might still need a more limited event trigger.

At least that is how I would approach the problem.

[yrashk]

Perhaps I did a bit too much induction by giving a loaded auth+http example without getting into the details of it.

Let's simplify it to get to the essence of the postulated topic.

The idea here is that when extension B is installed, extension A should provision more objects (irrespective of whether B was installed before A or after), without B being a hard requirement for A. Let's say extension A defines function do_something(int) and extension B provides type special_type. We want to define do_something over special_type.

A straightforward approach is indeed to make user install a third extension C that requires A and B and defines do_something over special_type. Works for simple cases but requires higher cognitive load for the operator of the database (more extensions to provision)

The approach I am playing with is to enable extension A to do something (such as provisioning do_something over special_type) whenever B is installed – whether by having its own event trigger or by using a centralized one.

Does this clarify my original writing?

[andreasscherbaum]

My view is that the best way to handle this is with a runtime check on HTTP server startup and/or triggered by a reload etc. I assume at the moment that this is a custom background worker (and that it doesn't listen on port 80 on *nix and so doesn't need root privileges). I would then allocate a memory context as a child of TopMemoryContext for runtime checks and configuration. Then I would make whatever runtime checks I wanted to do on startup and save the results there, You could also reserve, for example, SIGHUP to rerun these checks.

Without any kind of configuration this will lead to unpredictable results.

As example, depending on the presence of a library in a shared environment and enabling services based in that? This will enable the service even if no one actually wanted that service enabled.

[danolivo]

I have little experience designing constellations of extensions, but the idea with event trigger looks the best. As I remember, you connect all the extensions throughout the single connector, right? In that case, it makes sense to design a registration-based trigger subsystem that can help the extension identify the installation/drop of conflicting ones and, why not, execute some SQL scripts.