Thread: Re: [COMMITTERS] pgsql: Revert "Add libpq function PQhostaddr()."
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. And we would never consider removing a library API symbol
in a released branch.
I concur that PQhostaddr wasn't correctly documented, but maybe the
answer to that is to fix the documentation.
regards, tom lane
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.
Noah Misch <noah@leadboat.com> writes:
> On Sat, Nov 29, 2014 at 02:09:09PM -0500, Tom Lane wrote:
>> 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.
I don't plan to go to war over this, but it's not apparent to me that
PQhostaddr was such a broken concept that we should risk library
compatibility issues post-RC1. I will grant that *probably* there are
no users of the function yet, but why do we need to take the chance?
There are plenty of other access functions just like this one in libpq.
I think the bar for deciding that we can break compatibility at this
point is a lot higher than "well, maybe this isn't very useful".
regards, tom lane
Noah Misch-2 wrote > On Sat, Nov 29, 2014 at 02:09:09PM -0500, Tom Lane wrote: >> Noah Misch < > noah@ > > 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. Then the question becomes whether any backward incompatibility introduced in an RC release necessitates another RC release instead of going live with the next revision. I'll go with the idea that all betas and RC versions can have API changes but the release immediately preceding the actual release should not be allowed to do so. People who have tested their code on the most recent RC prior to release should be assured that when the final version is released that all API testing done previously is good. The RC is final release phase that our vendor community can use to polish their applications before end users are able to download the functionally equivalent final release. We do not want to force our vendors to have to finalize their 9.4 support in the short period between announcing the final release and it being made available in repositories. It is just as valid to insist that there will only be a single RC in which case API changes must not occur. But unles the community feels too burdened but an unbounded RC policy the ability to fix problems even during the RC phase seems valuable. These should be minor things so the biggest cost is the added RC release and not so much that applications end to be modified. David J. -- View this message in context: http://postgresql.nabble.com/Re-COMMITTERS-pgsql-Revert-Add-libpq-function-PQhostaddr-tp5828660p5828672.html Sent from the PostgreSQL - hackers mailing list archive at Nabble.com.
David G Johnston <david.g.johnston@gmail.com> writes:
> Noah Misch-2 wrote
>> 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.
> Then the question becomes whether any backward incompatibility introduced in
> an RC release necessitates another RC release instead of going live with the
> next revision. I'll go with the idea that all betas and RC versions can
> have API changes but the release immediately preceding the actual release
> should not be allowed to do so. People who have tested their code on the
> most recent RC prior to release should be assured that when the final
> version is released that all API testing done previously is good.
> The RC is final release phase that our vendor community can use to polish
> their applications before end users are able to download the functionally
> equivalent final release. We do not want to force our vendors to have to
> finalize their 9.4 support in the short period between announcing the final
> release and it being made available in repositories.
> It is just as valid to insist that there will only be a single RC in which
> case API changes must not occur. But unles the community feels too burdened
> but an unbounded RC policy the ability to fix problems even during the RC
> phase seems valuable. These should be minor things so the biggest cost is
> the added RC release and not so much that applications end to be modified.
Well, personally, as one of the people on whom the burden of an extra RC
release would fall, let me make it clear that there will *not* be an RC2
release just for this. If the community consensus is that this change
would require us to do an RC2, it's going to get reverted.
regards, tom lane