Aidan Van Dyk <ai...@highrise.ca> writes: > On Fri, Feb 11, 2011 at 7:19 PM, Tom Lane <t...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers