On Dec 26, 2024, at 20:09, Andrei Lepikhov <lepi...@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
signature.asc
Description: Message signed with OpenPGP
