Re: [COMMITTERS] pgsql: Revert "Add libpq function PQhostaddr()." - Mailing list pgsql-hackers

From Noah Misch
Subject Re: [COMMITTERS] pgsql: Revert "Add libpq function PQhostaddr()."
Date
Msg-id 20141129193125.GD1249202@tornado.leadboat.com
Whole thread Raw
In response to Re: [COMMITTERS] pgsql: Revert "Add libpq function PQhostaddr()."  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: [COMMITTERS] pgsql: Revert "Add libpq function PQhostaddr()."  (Tom Lane <tgl@sss.pgh.pa.us>)
Re: [COMMITTERS] pgsql: Revert "Add libpq function PQhostaddr()."  (David G Johnston <david.g.johnston@gmail.com>)
List pgsql-hackers
On Sat, Nov 29, 2014 at 02:09:09PM -0500, Tom Lane wrote:
> Noah Misch <noah@leadboat.com> writes:
> > Revert "Add libpq function PQhostaddr()."
> > This reverts commit 9f80f4835a55a1cbffcda5d23a617917f3286c14.  The
> > function returned the raw value of a connection parameter, a task served
> > by PQconninfo().  The next commit will reimplement the psql \conninfo
> > change that way.  Back-patch to 9.4, where that commit first appeared.
> 
> I confess to not having been paying too much attention to your discussion
> with Fujii over the holiday, but isn't it a bit too late to be making
> client-API-breaking changes in 9.4?  I would have been fine with this
> before RC1 went out, but once we do that, the branch should be treated
> as released.

I had considered that, and one could make a reasonable case for living with
the new symbol on that basis.  For the release candidate stage to have value,
though, the "treat as released" principle must not be absolute.  I regret not
noticing the problem earlier.



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: [COMMITTERS] pgsql: Revert "Add libpq function PQhostaddr()."
Next
From: Stephen Frost
Date:
Subject: Re: Review of GetUserId() Usage