Formulae of PostgreSQL extensions

[svoop]

Output of brew config

n/a

Output of brew doctor

n/a

Description of issue

The current situation for PostgreSQL extensions adds a dependency from the unversioned extension formula to the versioned PostgreSQL formula.

A notorious example ist PostGIS which as of today still depends on postgresql@14 even though the newest version is postgresql@16. As PostgreSQL releases one major per year, PostGIS now enforces the use of a PostgreSQL version that's more than 2 years old and will reach EOL in November 2026.

The obvious problem with PostgreSQL extensions: The versions of extensions follow their own rules and are not linked to PostgreSQL. Usually, a specific version of the extension can be used with different versions of PostgreSQL, therefore versioning PostgreSQL extension formulae the "normal way" doesn't help.

To work around this, @ozeias has created a postgis@15 formula which pulls a (custom) version of postgresql@15. (Simple version bumps are sufficient to make his formulae work for @16 as well.)

TL;DR I propose using versions in a different manner for PostgreSQL extensions: Formulae which provide PostgreSQL extensions use versioning synced to the corresponding version of PostgreSQL. For example:

• postgresql@14 is pulled by postgis@14 (which is postgis-3.3.6)
• postgresql@15 is pulled by postgis@15 (which is postgis-3.3.6)
• postgresql@16 is pulled by postgis@16 (which is postgis-3.3.6)
• postgresql@17 will be pulled by postgis@17 (which will be at least postgis-3.4.x according to the version matrix)

I know, this is kind of a hack, but IMO a reasonable one. It's far more likely for project developers to require a specific version of PostgreSQL and if the project uses an PostgreSQL extension, things get ugly. In the less likely case the extension itself has to be versioned, this version could be postfixed: postgis@16-3-4.

What do you think, would this be a way forward out of the current deadlock? Or are there better ways to address this with minimal impact on Homebrew?

Related to #3987

[SMillerDev]

Seeing how, despite repeated attempts, nobody managed to get postgis updates to work. I think deprecation and deleting the formula is more likely.

[SMillerDev]

I think we shouldn't be adding versions if we can't get one formula to work.

[cho-m]

The problem right now is that only a single postgresql@x formula is currently able to support extensions.

In order for extensions to work, the corresponding postgresql@x formula needs to be linked into HOMEBREW_PREFIX path and the path needs to be burned into binaries at build-time, e.g. via --datadir, --libdir, and --includedir: https://github.com/Homebrew/homebrew-core/blob/master/Formula/p/postgresql%4014.rb#L55-L57

      --datadir=#{HOMEBREW_PREFIX}/share/#{name}
      --libdir=#{HOMEBREW_PREFIX}/lib/#{name}
      --includedir=#{HOMEBREW_PREFIX}/include/#{name}

This also means the postgresql@x formulae must not be keg_only otherwise it cannot find its own files.

However, for versioned formulae, we only allow removing keg_only when the formulae can be simultaneously installed. We do not allow conflicting versioned formulae https://github.com/Homebrew/brew/blob/master/Library/Homebrew/rubocops/conflicts.rb#L13-L14

        MSG = "Versioned formulae should not use `conflicts_with`. " \
              "Use `keg_only :versioned_formula` instead."

---

So, PostgreSQL extension formulae in homebrew-core must all be migrated at same time to a single postgresql@x version.

[svoop]

@cho-m Thanks for the explanation.

PostgreSQL extension formulae in homebrew-core must all be migrated at same time to a single postgresql@x version.

So for the sake of updating other extensions, PostGIS might be dumped. Guess I'll have to switch from Brew to containers at some point. 😢

[cho-m]

If PostGIS build can be fixed, it will remain. However, we will most likely move all extensions to latest PostgreSQL whenever anyone has chance to write up a PR. We used to do this implicitly when we had an unversioned postgresql formula.

This also means if you need a specific version of PostgreSQL with PostGIS support, then another alternative is probably necessary. As you mentioned, this can be containers or a third-party tap. There are also PostgreSQL extension managers but I can't comment on how well they work with Homebrew's postgresql@ formulae.

[ozeias]

It is possible to fix the PostGIS build issue. However, in my opinion, the real problem is not with PostGIS itself but rather how the default version of postgresql@14 is configured vs. new versions - try brew info postgresql. Installing any extension with any PostgreSQL version other than postgresql@14 is challenging.