[Slackbuilds-users] PostgreSQL - multiple installed versions

[JK Wood]

On Sep 3, 2013 10:03 PM, "Benjamin Trigona-Harany" <bosth at alumni.sfu.ca>
wrote:
>
> On September 3, 2013 17:04:15 Adis Nezirovic wrote:
> > Guys, I have a question for all PostgreSQL users and SBo admins.
> >
> > Would it be OK for the next PostgreSQL package (upcoming 9.3) to be
version
> > specific and parallel-installable with  old PostgreSQL versions.
> > (of course, we would continue that practice in the future).
> >
> > Since PostgreSQL installations are not upgradeable in place, one needs
to
> > do export/import data cycle or use pg_upgrade utility, and having old
and
> > new database instance would be very handy for that.
> >
> > The packages would be named postgresql93 (v9.3.x), postgresql94 (v9.4.x)
> > (the current postgresql can be treated as postgresql92), and would use
> > version specific data directories.
>
> This is timely because a similar issue just came up with the 2.2 release
of
> PostGIS, which also expects both the current 2.2 and the previous 2.1
versions
> installed to do an in-place upgrade of existing databases.
>
> However, providing both postgis21 and postgis22 SlackBuilds would mean
some
> headaches for packages depending on PostGIS since it wouldn't be evident
which
> version of PostGIS it was built against without also versioning that build
> script.
>
> Likewise, splitting PostgreSQL into version-dependent scripts is going to
> affect dependencies. Other distros have ended up with packages such as
> postgres91-postgis21-2.1.0, but I don't see that being maintainable,
> especially when we consider the further SlackBuilds that will depend on
that
> package.
>
> Ben
> _______________________________________________
> SlackBuilds-users mailing list
> SlackBuilds-users at slackbuilds.org
> http://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users
> Archives - http://lists.slackbuilds.org/pipermail/slackbuilds-users/
> FAQ - http://slackbuilds.org/faq/
>
>

Speaking as someone who works with databases professionally, if you don't
have a way of maintaining an upgrade path you have bigger problems.

Speaking as someone who maintains a few packages, having two differing
packages won't solve the problem, which is overwriting the tools when you
install the new package.

It really sounds to me like an upgrade script which takes care of the
necessary steps for an upgrade would be infinitely preferable, and should
be done in addition to the current SlackBuild.

--JK
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.slackbuilds.org/pipermail/slackbuilds-users/attachments/20130903/ba05ab33/attachment-0001.html>