Skip to content
Permalink

Comparing changes

Choose two branches to see what’s changed or to start a new pull request. If you need to, you can also or learn more about diff comparisons.

Open a pull request

Create a new pull request by comparing changes across two branches. If you need to, you can also . Learn more about diff comparisons here.
base repository: postgresql-cfbot/postgresql
Failed to load repositories. Confirm that selected base ref is valid, then try again.
Loading
base: cf/5465~1
Choose a base ref
...
head repository: postgresql-cfbot/postgresql
Failed to load repositories. Confirm that selected head ref is valid, then try again.
Loading
compare: cf/5465
Choose a head ref
  • 3 commits
  • 98 files changed
  • 2 contributors

Commits on Mar 23, 2025

  1. Introduce PG_MODULE_MAGIC_EXT macro. 

    This macro allows dynamically loaded shared libraries (modules) to
provide a wired-in module name and version, and possibly other
compile-time-constant fields in future.  This information can be
retrieved with the new pg_get_loaded_modules() function.

This feature is expected to be particularly useful for modules
that do not have any exposed SQL functionality and thus are
not associated with a SQL-level extension object.  But even for
modules that do belong to extensions, being able to verify the
actual code version can be useful.

Author: Andrei Lepikhov <[email protected]>
Reviewed-by: Yurii Rashkovskii <[email protected]>
Reviewed-by: Tom Lane <[email protected]>
Discussion: https://postgr.es/m/[email protected]
    @tglsfdc
    tglsfdc authored and Commitfest Bot committed Mar 23, 2025
    Configuration menu
    Copy the full SHA
    ec1ab7e View commit details
    Browse the repository at this point in the history

  2. Use PG_MODULE_MAGIC_EXT in our installable libraries. 

    It seems potentially useful to label our shared libraries with version
information, now that a facility exists for retrieving that.  This
patch labels them with the PG_VERSION string.  There was some
discussion about using semantic versioning conventions, but that
doesn't seem terribly helpful for modules with no SQL-level presence;
and for those that do have SQL objects, we typically expect them
to support multiple revisions of the SQL definitions, so it'd still
not be very helpful.

I did not label any of src/test/modules/.  It seems unnecessary since
we don't install those, and besides there ought to be someplace that
still provides test coverage for the original PG_MODULE_MAGIC macro.

Author: Tom Lane <[email protected]>
Discussion: https://postgr.es/m/[email protected]
    @tglsfdc
    tglsfdc authored and Commitfest Bot committed Mar 23, 2025
    Configuration menu
    Copy the full SHA
    76c9f13 View commit details
    Browse the repository at this point in the history

  3. [CF 5465] v7 - Add maintainer-defined module info into shared library 

    This branch was automatically generated by a robot using patches from an
email thread registered at:

https://commitfest.postgresql.org/patch/5465

The branch will be overwritten each time a new patch version is posted to
the thread, and also periodically to check for bitrot caused by changes
on the master branch.

Patch(es): https://www.postgresql.org/message-id/[email protected]
Author(s): Andrei Lepikhov
    Commitfest Bot committed Mar 23, 2025
    Configuration menu
    Copy the full SHA
    1378c96 View commit details
    Browse the repository at this point in the history
Loading