Re: Tom Lane 2014-05-02 <9995.1398994...@sss.pgh.pa.us>
> >> The patch is certainly too invasive to consider back-patching into
> >> 9.3, though.
Understood.
> > I feel unsure about this. I agree the patch is quite invasive. Leaving
> > 9.3 in a broken state seems problematic. In particular I'm not sure
> > what would Debian do about the whole issue; would they have to carry the
> > patch for their 9.3 packages?
>
> My recommendation to Christoph upthread was that they just look the
> other way for the time being, ie, ignore the fact that relpath.h is
> unusable by freestanding apps in 9.3. Backpatching what I did for
> 9.4 would be an ABI break, so that seems to me to be out of the
> question in 9.3. And it's not clear that anybody outside core+contrib
> really needs relpath.h yet, anyway. (Of course, you could argue that
> if there are no external users then the ABI break isn't a problem;
> but if there are, then it is.)
We are certainly not going to replace the old mess by a custom new
one ;)
The original problem that postgres_fe.h wasn't usable is already fixed
for 9.3, so afaict the only remaining problem there seems the
installation {rule, location} of common/, which is either taken care
of by the patch I've sent, or a trivial addition to the packaging
files on our side.
As long as there's no complaints, we'll simply ignore the fact that
the other headers in 9.3's common/ aren't self-contained, the
workaround to simply install the server headers seems easy enough.
We should probably be able to move to 9.4 in time for the freeze of
Debian Jessie in November, so backports won't matter that much. (As
long as the 9.3-and-older server-headers are self-contained and/or
compatible with what 9.4 provides...)
Christoph
--
c...@df7cb.de | http://www.df7cb.de/
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
