Thread: DSO Terms Galore

Hackers,

I’m trying to understand the standard terms for extension libraries. There seem too a bewildering number of terms used
torefer to a shared object library, for example: 

* LOAD[1]:
  * “shared library”
  * “shared library file”
* dynamic_library_path[2]:
  * “dynamically loadable module”
* xfunc-c[3]:
  * “dynamically loadable object”
  * “shared library”
  * “loadable object”
  * “loadable object file”
  * “object file”
  * “dynamically loaded object file”
* pg_config[5]:
  * “object code libraries” (static?)
  * “dynamically loadable modules”
* PGXS[4]:
  * “MODULES”
  * “shared-library objects”
  * “shared library”

Bonus confusion points to PGXS for MODULEDIR having nothing to do with MODULES.

What is the standard term for these things? Or perhaps, what *should* it be? “Module”? “Library”? “Object”? “Shared
____”?“Dynamic ____”? 

Would it be useful to decide on one term (perhaps with “file” appended where it refers to a file that contains one of
thesethings) and standardize the docs? 

Confusedly yours,

David

[1]: https://www.postgresql.org/docs/current/sql-load.html
[2]: https://www.postgresql.org/docs/current/runtime-config-client.html#GUC-DYNAMIC-LIBRARY-PATH
[3]: https://www.postgresql.org/docs/current/xfunc-c.html
[4]: https://www.postgresql.org/docs/current/extend-pgxs.html
[5]: https://www.postgresql.org/docs/current/app-pgconfig.html

On Fri, Jul 19, 2024 at 03:27:49PM -0400, David E. Wheeler wrote:
> I´m trying to understand the standard terms for extension libraries.
> There seem too a bewildering number of terms used to refer to a shared
> object library, for example:
>
> [...] 
> 
> What is the standard term for these things? Or perhaps, what *should* it
> be? "Module"? "Library"? "Object"? "Shared ____"? "Dynamic ____"?
> 
> Would it be useful to decide on one term (perhaps with "file" appended
> where it refers to a file that contains one of these things) and
> standardize the docs?

The lack of consistent terminology seems at least potentially confusing for
readers.  My first reaction is that "shared library" is probably fine.

-- 
nathan

On Jul 19, 2024, at 15:46, Nathan Bossart <nathandbossart@gmail.com> wrote:

> The lack of consistent terminology seems at least potentially confusing for
> readers.  My first reaction is that "shared library" is probably fine.

That’s the direction I was leaning, as well, but I thought I heard somewhere that the project used the term “module”
forthis feature specifically. That would be a bit nicer for the new PGXN Meta Spec revision I’m working on[1], where
thesethree different types of things could be usefully separated: 

* extensions: CREATE EXTENSION extensions
* modules: loadable modules for extensions, hooks, and workers (anything else?)
* apps: Programs and scripts like pg_top, pgAdmin, or pg_partman scripts[2]

Here the term “libraries” would be a little over-generic, and “share_libraries” longer than I'd like (these are JSON
objectkeys). 

Best,

David

[1]: https://github.com/pgxn/rfcs/pull/3
[2]: https://github.com/pgpartman/pg_partman/tree/master/bin/common

On 19.07.24 21:27, David E. Wheeler wrote:
> I’m trying to understand the standard terms for extension libraries. There seem too a bewildering number of terms
usedto refer to a shared object library, for example:
 
> 
> * LOAD[1]:
>    * “shared library”
>    * “shared library file”
> * dynamic_library_path[2]:
>    * “dynamically loadable module”
> * xfunc-c[3]:
>    * “dynamically loadable object”
>    * “shared library”
>    * “loadable object”
>    * “loadable object file”
>    * “object file”
>    * “dynamically loaded object file”
> * pg_config[5]:
>    * “object code libraries” (static?)
>    * “dynamically loadable modules”
> * PGXS[4]:
>    * “MODULES”
>    * “shared-library objects”
>    * “shared library”

I think in the POSIX-ish realm, the best term is "dynamically loadable 
library".  It's a library, because it contains functions you can, uh, 
borrow, just like a static library.  And it's dynamically loadable, as 
opposed to being loaded in a fixed manner at startup time.

Also, the "dl" in dlopen() etc. presumably stands for dynamic-something 
load-something.

Libtool uses the term "dlopened module" for this, and the command-line 
option is -module. 
(https://www.gnu.org/software/libtool/manual/libtool.html#Dlopened-modules)

Meson uses shared_module() for this.  (It has shared_library() and 
static_library() for things like libpq.)

Things like "object" or "object file" or probably wrong-ish.  I 
understand an object file to be a .o file, which you can't dlopen directly.

Shared library is semi-ok because on many platforms, link-time shared 
libraries (like libpq) and dynamically loadable libraries (like plpgsql) 
are the same file format.  But on some they're not, so it leads to 
confusion.

I think we can unify this around terms like "dynamically loadable 
library" and "dynamically loadable module" (or "loaded" in cases where 
it's talking about a file that has already been loaded).

On Jul 23, 2024, at 07:26, Peter Eisentraut <peter@eisentraut.org> wrote:

> Things like "object" or "object file" or probably wrong-ish.  I understand an object file to be a .o file, which you
can'tdlopen directly. 

Agreed.

Another option, however, is “dynamically shared object” (DSO), which corresponds to the usual *nix extension, .so. I
thinkI know the term most from Apache. It’s curious that I didn’t run across it while perusing the Postgres docs. 

> I think we can unify this around terms like "dynamically loadable library" and "dynamically loadable module" (or
"loaded"in cases where it's talking about a file that has already been loaded). 

+1 for “dynamically loadable module” and, in common usage, “module”, since I don’t think it would be confused for
anythingelse. “dynamically loadable library” would either have to always be used in full --- because “library” can be
static,too --- or to “DLL”, which has strong Windows associations. 

Best,

David