Jeff Janes wrote: > I am facing a scenario where I have different version of an extension, say 1.0 and 2.0, which have > some different functionality between them (so not merely a bug fix), so people might want to continue > to use 1.0. > > But changes to the PostgreSQL software between major versions requires changes to the extension's > source code. > > So I basically have 4 versions to carry: > > 1.0_for_9.4_or_before > 2.0_for_9.4_or_before > 1.0_for_9.5 > 2.0_for_9.5 > > > Is there some easy way to handle this? Are there examples of existing modules which have a similar > situation (and which handle it well) on PGXN or pgfoundry or other public repositories?
I don't think that there is an easy solution.
Could some #ifdefs make the same code work for 9.4 and 9.5?
Probably. But I probably shouldn't just pretend that the #ifdefs were there all along for the already-released code. So if 1.0 was already in the wild while 2.0 was not, you would still be left with something like:
1.0_for_9.4_or_before (perhaps make it uninstallable for new installations)
1.1_for_any_version_(so_far)
2.0_for_any_version_(so_far)
It seems like there should be some way to mark a feature-release of an extension, versus a server-compatibility-only release (also versus a bug-fix-in-extension release).
