[Bug 201796] Mk/bsd.default-versions.mk: Set PostgreSQL 9.4 as default

[bugzilla-noreply at freebsd.org]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=201796

--- Comment #14 from Mathieu Arnold <mat at FreeBSD.org> ---
(In reply to Palle Girgensohn from comment #13)
> (In reply to Torsten Zühlsdorff from comment #12)
> 
> Vi had a discussion about this within the pgsql@ team, and one way might be
> to extract libpq to a separate port, och make USES=pgsql just pull in that
> dependency. That would always be the latest version, since libpq is very
> stable, it rarely changes at all. Then we could install the rest of
> postgresqlNN-client and postgresqlNN-server in it's own
> (lib|share|include)/postgresqlNN directories, and use some kind of meta-port
> to symlink to the preferred version.
> 
> It would mean we could install several postgresql versions in parallel. This
> is a complex task though, and it might not even be completely possible
> without too much intrusive changes to postgresql. I will discuss this with
> some other packagers first. So this should probably be regarded as a
> possible long term solution at best.
> 
> We do however need some way of helping users to get two different versions
> of postgresql binaries in just for the sake of facilitating an upgrade
> running pg_upgrade. The most simple way would probably be a separate port,
> but that woud be a bit weird.
> 
> Other ideas?

Moving pg_upgrade from -contrib to -server would be great, people have been
asking this for a long time.

Most package systems are able to install more than one postgresql at a time,
though we don't really need that, what we need is to be able to upgrade, it
means that there should be a package with older bin/postgres binaries (it's the
only one needed for pg_upgrade, along with the .so it needs, of course.)

Maybe the postgresqlXX-server package could include them.

-- 
You are receiving this mail because:
You are on the CC list for the bug.