Fedora (28+) already provides multiple versions of PostgreSQL packages, the
default version AND the modular version (even though DB team has not started
maintaining the modular PG stack, it's done by modularity people - available
for testing in /etc/yum.repos.d/fedora-modular.repo).

The ongoing plan is to support the modular PostgreSQL server, too, and make
that server interchangeable with system-default version (note that this is
not about parallel install-ability/SCL!).

The new layout should be 100% compatible with what we have provided so far,
so regular user shouldn't really observe big differences.  I.e. each Fedora
version should still (by default) provide/install the latest PostgreSQL
major server version which was available at the time of Fedora branching
(from Fedora Rawhide).

So the change is that, in module repository (in module streams), we'll
provide different versions of set of PostgreSQL server packages
(postgresql-server, postgresql-contrib, postgresql-pl*, etc., + third party
modules built against that server).

The major change in 'postgresql.spec' is that we'll drop shared libraries
from there - the postgresql-libs subpackage.  Newly the contents of
postgresql-libs subpackage will be provided in 'libpq' and 'libecpg'
packages (with *-devel counterparts).  The benefit of this layout is that,
even though servers will be distributed in multiple versions, the _client_
library can be built and maintained only once per system.

We expect to provide older PG stack version usually in modules, but it _is_
expected (we at least wish) that we could even start shipping newer version of
PostgreSQL server module in the middle of Fedora stable release.  For this
purpose, we might need to have libpq updated to newer major version (if the
newly provided server version will require a newer libpq, e.g. because there
are newer symbols).  So to automatically guard against server/client-lib
mis-installation, we'll start with small downstream change -- with versioned
ABI of the libpq library.

This approach (single version of libpq and ABI versioning) has been
discussed upstream and the result is that:

  - Debian packagers do something similar (slightly differently because
    they maintain several libpq.so.5 versions in parallel, but only
    the latest required libpq is installed)

  - upstream is not ATM very much interested in ABI versioning support

If upstream decided to implement ABI versioning one day, we'd migrate to
that scheme in the next branched distro version.

[1] https://www.postgresql.org/message-id/5261375.z5KIV9Ssac%40nb.usersys.redhat.com

This bug is meant to serve the tracking purpose.