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

  1. Avoid mixing designated and non-designated field initializers.

  2. Use PG_MODULE_MAGIC_EXT in our installable shared libraries.

  3. Introduce PG_MODULE_MAGIC_EXT macro.