Re: [COMMITTERS] pgsql: Revert "Add libpq function PQhostaddr()."
| От | Tom Lane |
|---|---|
| Тема | Re: [COMMITTERS] pgsql: Revert "Add libpq function PQhostaddr()." |
| Дата | |
| Msg-id | 29559.1417291608@sss.pgh.pa.us обсуждение исходный текст |
| Ответ на | Re: [COMMITTERS] pgsql: Revert "Add libpq function PQhostaddr()." (Noah Misch <noah@leadboat.com>) |
| Список | pgsql-hackers |
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
В списке pgsql-hackers по дате отправления: