On 12/27/24 01:26, David Wheeler wrote:
On Mon, Dec 23, 2024, at 8:49 PM, Andrei Lepikhov wrote:
Looking into the control file, I see that most parameters are
unnecessary for the library. Why do we have to maintain this file?
Well, either way you have to load the extension, either CREATE EXTENSION to
load an SQL extension (and any related shared modules), or LOAD or
*_preload_libraries to load a shared module. I propose to add support for
shared-module-only extensions to CREATE/UPDATE/DROP EXTENSION. It would then
both insert the version info in the database (from the control file, at least),
and load the shares module(s).
I still can't get your point.
We intentionally wrote a library, not an extension. According to user
usage and upgrade patterns, it works across the whole instance and in
any database or locally in a single backend and ends its impact at the
end of its life.
Also, it doesn't maintain any object in the database and is managed by GUCs.
For example, my libraries add query tree transformations/path
recommendations to the planner. It doesn't depend on a database and
doesn't maintain DSM segments and users sometimes want to use it in
specific backends, not databases - in a backend dedicated to analytic
queries without extra overhead to backends, picked out for short
queries. For what reason do I need to add complexity and call 'CREATE
EXTENSION' here and add version info only in a specific database? Just
because of a formal one-directory structure?
--
regards, Andrei Lepikhov
