Re: Add Postgres module info

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
sharedmodules), or LOAD or *_preload_libraries to load a shared module. I propose to add support for shared-module-only
extensionsto 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