Re: RFC: Extension Packaging & Lookup

On Nov 7, 2024, at 10:30, David E. Wheeler <david(at)justatheory(dot)com> wrote:

> Last week I tried to integrate all the ideas into this thread and the previous[1] into a single proposal that attempts to work through all the implications and issues. I’ve drafted it as a blog post[2] and plan to publish it next week, following some more feedback. Would appreciate comments, corrections, and any other general feedback:
>
> https://github.com/theory/justatheory/pull/7

Got some good feedback on this, in particular about how I might be overthinking separate destinations for core vs. package-installed vs. user-installed extensions. The RFC proposes separate directories and variables for core/vendor/site extensions, borrowing the idea from various dynamic language systems.

I came to this thinking that it was important to keep core (contrib, PL) extensions separate from non-core extensions, and if so, it’d be useful to have other defaults so that `make install` would go to the right one (site by default).

But maybe it’s not necessary? If there are no extensions by default, perhaps it doesn’t matter?

But of course there are some by default. I just ran `make all && make install`, and `share/extension` contains files for plpgsql (and plperl, but I presume it could be separated). Meanwhile, `lib` is full of a _ton_ of files.

Would it not be beneficial to have by-default empty directories into which extensions and modules are installed that don’t come with core? Or should they *all* be considered one thing? If the latter, perhaps truly core modules should be stored separately?

Best,

David