Re: Add Postgres module info
David E. Wheeler <david@justatheory.com>
From: "David E. Wheeler" <david@justatheory.com>
To: Andrei Lepikhov <lepihov@gmail.com>
Cc: Euler Taveira <euler@eulerto.com>,
Andres Freund <andres@anarazel.de>,
Tom Lane <tgl@sss.pgh.pa.us>,
pgsql-hackers <pgsql-hackers@postgresql.org>
Date: 2024-12-27T22:02:56Z
Lists: pgsql-hackers
On Dec 26, 2024, at 20:09, Andrei Lepikhov <lepihov@gmail.com> wrote: > 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. The same is true for the shared libraries included in many extensions. A shared library is just an extension that’s available in all databases and has no associated SQL interface. > Also, it doesn't maintain any object in the database and is managed by GUCs. Sure, but this is just a semantic argument. The Postgres developers get to decide what terms mean. I’m I argue it can be worthwhile to merge the idea of a library into extensions. > 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? Perhaps shared-library only extensions are not limited to a single database. Best, David
Commits
-
Avoid mixing designated and non-designated field initializers.
- d66997dfe8fe 18.0 landed
-
Use PG_MODULE_MAGIC_EXT in our installable shared libraries.
- 55527368bd07 18.0 landed
-
Introduce PG_MODULE_MAGIC_EXT macro.
- 9324c8c58065 18.0 landed