From: | Albe Laurenz <laurenz(dot)albe(at)wien(dot)gv(dot)at> |
---|---|
To: | "'Jeff Janes *EXTERN*'" <jeff(dot)janes(at)gmail(dot)com>, "pgsql-general(at)postgresql(dot)org" <pgsql-general(at)postgresql(dot)org> |
Subject: | Re: Version management for extensions |
Date: | 2015-10-09 08:36:29 |
Message-ID: | A737B7A37273E048B164557ADEF4A58B50FB6F68@ntex2010i.host.magwien.gv.at |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
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?
Yours,
Laurenz Albe
From | Date | Subject | |
---|---|---|---|
Next Message | Bill Moran | 2015-10-09 11:27:50 | Re: Drop or alter column under load give ERROR #42804 structure of query does not match function result type: |
Previous Message | Oleksii Kliukin | 2015-10-09 07:24:39 | Re: dubious optimization of the function in SELECT INTO target list |