PGConf.dev 2025 Extension Summit

The 2025 Extension Ecosystem Summit took place at PGConf.dev in Montréal on May 13, 2025. This was an Open Space Technology/Unconference-style session in which attendees identified topics to address, self-selected into teams, and discussed them. This page records the notes taken from each session.

Notes from Break-out Sessions

Breakout on what should be in core / contrib / a 3rd party extension

Two examples which started this discussion are pg_stat_statements feels like a core function and auto-explain provides plan logging infrastructure for plan visibility improvements in a number of areas. If we're putting the ability to log long running plans in core, but not all all plans, it feels inconsistent.

Is the question why it should be core or why it should be an extension?

New possible levels beyond core -> contrib -> 3rd part extension

• Maybe some contrib extensions should move into testing only
• Document third party extensions in some way to make the classes of functionality visible

Since the committers are all in other meeting, we only have the voices in the room who want to move things towards core. We know there has been interest in moving some of contrib out, but those folks weren't here.

Tradeoff between trust in core and contrib code, speed of build and release of 3rd party extensions, the option of releasing 3rd party extensions for older versions, and managing the maintenance overhead on the core community.

A reason to move things towards core is if there's core feature which don't work without the extension - btree-gist as an example - exclusion constraints don't work properly without them. Logical replication's role in upgrades may provide another example.

A reason to push things towards a third party extension is if the work has proven too controversial or large to review in core. Logical replication was in this category and eventually moved in, TDE is a current example. A reason not to move things away from contrib (other than into testing) is to ensure that the hooks/callbacks provided by core are at least smoke tested.

For functionality currently provided by contrib (like pg_stat_statements), installing the extension by default may be a good alternative to moving the functionality into core. This may make the problem of moving one extension from an area of functionality into core wiping out all the similar extensions in the ecosystem.

Is there a place for an extension advancement ladder? Might pg_audit be an example of something which could/should move into contrib?

Breakout on ideas for new hooks

A parser hooks to add more grammar flexibility for extensions

A new logging hook, based on the pg_audit can only log to the logfile, therefore providing a hook to be able to send to logs to a different target.

A new Logging hook that provides the unformatted data, to provide more flexibility for the extension to format the hook and for the extension to format the log at a later time.

Ability for hooks to be able to track the stack. The example given is the permissions hooks being called without the ExecutorStart hook.

autovacuum launcher hooks to be let extensions override the current autovacuum scheduling which could help drive new ideas/improvements for autovacuum scheduling based on different criteria.

Upgrading Extensions

• Problems:
  • Massive update scripts + all possible versions (David Steele)
  • pgAudit: Minor upgrades have scripts, major upgrades force reinstall
  • Extensions has types and views (Paul Ramsey)
    • Dependencies problems while uninstalling and reinstalling
• Ideas:
  • Can we have a pre-check
    • Requires backwards compatible
    • Almost impossible to do
  • Make it possible to load multiple versions, and multiple binaries
    • Problems with background workers
    • Allows rolling back and forth between versions
    • Possibly wrap everything (including loading the library) into the transaction
    • Have a registration process for hooks
      • Make it possible to profile hooks
    • Version the library file
      • Redo all the functions, pg_proc doesn't know about extensions
    • Lock everyone out for the extension upgrade
      • There might be per session state
      • Hook for invalidation handler
    • Introduce modules
      • Point to module in `pg_proc`instead of a `.so` file
  • State tables
    • Will be dropped when extension is dropped

From later discussion:

• Extension usage counter
  • Some kind of hook, called async, which counts usage