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
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 |