Re: Hokey wrong versions of libpq in apt.postgresql.org

* Tom Lane (tgl(at)sss(dot)pgh(dot)pa(dot)us) wrote:
> We only bump the SO version when we make a low-level ABI break; but even
> without doing that we could potentially have changed library behavior in
> ways that could negatively impact some applications.

We should definitely be paying attention for such cases as I'd generally
feel that they're bug fixes we need to address..

> So I think there's
> some merit in Josh's position: he doesn't want to have to re-QA his
> applications against some new version of libpq, but if you force him to
> move to 9.3 libpq, he's going to need to do that if he wants to be strict
> about it.

"Force" is a bit strong here, in my opinion. There's a (really, rather
trivial) way to get the libpq version which is shipped with a specific
PG major version- simple add that major version to the end of the 'deb'
line in your sources.list file.

> If the Debian guidelines think that only SO major version need
> be considered, they're wrong, at least for the way we've been treating
> that.

The SO major version should be sufficient for applications to operate
normally. If that isn't the case then I agree that we need to review
the changes we are making to see if the SO should be bumped. Note that
Debian's viewpoint on this is more along the lines of "why build against
an old version if the latest one, whose major SO is the same, exists?"
This is largely to avoid the hell of versioned Build-Depends and having
to support multiple sets of -dev packages concurrently (consider that
builds generally only look for the unversioned '.so' file also..).

> At the same time, there would be more merit in Josh's position if he
> could point to any *actual* libpq changes that might pose application
> compatibility problems. I don't recall that we've made many such,
> so the above argument might just be hypothetical.

I don't believe it's hypothetical from Josh's perspective, but I didn't
follow the threads completely to confirm that there was a real issue.
If there is a real issue here, I'd most likely vote to fix it and
backpatch it as a bug, though it's not clear if that would be considered
'good enough' for this case.

Thanks,

Stephen