RE: [PATCH] Support % wildcard in extension upgrade filenames

From: "Regina Obe" <lr(at)pcorp(dot)us>
To: "'Mat Arye'" <mat(at)timescaledb(dot)com>
Cc: <strk(at)kbt(dot)io>, "'Yurii Rashkovskii'" <yrashk(at)gmail(dot)com>, "'Tom Lane'" <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "'Regina Obe'" <r(at)pcorp(dot)us>, <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: RE: [PATCH] Support % wildcard in extension upgrade filenames
Date: 2023-04-24 18:00:30
Message-ID: 002301d976d6$a934d0b0$fb9e7210$@pcorp.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

> This change also makes it easier for extensions that use versioned .so files (by that I mean uses extension-<version>.so rather than extension.so).
> Because such extensions can't really use the chaining property of the existing upgrade system and so need to write a direct X--Y.sql migration file for
> every prior version X. I know the system wasn't designed for this, but in reality a lot of extensions do this. Especially the more complex ones.

> Hopefully this is helpful,
> Mat

Thanks for the feedback. Yes this idea of versioned .so is also one of the reasons why we always have to run a replace on all functions.

Like for example on PostGIS side, we have option of full minor (so the lib could be postgis-3.3.so or postgis-3.so)

For development I always include the minor version and the windows interim builds I build against our master branch has the minor.
But the idea is someone can upgrade to stable version, so the script needs to always have the .so version in it to account for this shifting of options.

Thanks,
Regina

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Phil Florent 2023-04-24 18:37:30 RE: Should we remove vacuum_defer_cleanup_age?
Previous Message Yurii Rashkovskii 2023-04-24 17:43:51 Re: [PATCH] Extend the length of BackgroundWorker.bgw_library_name