Aidan Van Dyk <aidan@highrise.ca> writes:
> On Fri, Feb 11, 2011 at 7:19 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> No, you ship *one* package that supports both 1.1 and 2.0.
> Hm... As an example of a project that generally has pretty good
> software release practices, I'm glat that the PostgreSQL project
> doesn't operate this way.
> Having to download/install/upgrade a package with all of pg
> 9.1.$lateset and 9.0.$latest just to get a fix for 8.4.$latest would
> be a bit of a bummer...
I don't see that this proposal changes anything about that. It's still
the case that the underlying .so is tied to a major PG version. What
you'll ship is a control file and assorted .sql files that represent the
user APIs you are interested in supporting on that major PG version.
For systems like Debian that support concurrent installation of multiple
major PG versions, you would be installing all these files into a
version-specific share/ directory.
If you don't feel like supporting multiple API versions on a given PG
major release, then nothing much changes from the way you packaged
stuff before. The only real change is that you have a fairly clean way
to package scripts that fix bugs in the extension's catalog entries,
which was something that could only be done in a very ad-hoc way before.
If you were expecting this proposal to make things easier as far as
dealing with multiple major releases, sorry, our ambitions don't extend
that far yet.
regards, tom lane