Re: -d option for pg_isready is broken

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: -d option for pg_isready is broken
Дата
Msg-id 3058.1386790193@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: -d option for pg_isready is broken  (Robert Haas <robertmhaas@gmail.com>)
Ответы Re: -d option for pg_isready is broken
Список pgsql-hackers
Robert Haas <robertmhaas@gmail.com> writes:
> On Wed, Dec 11, 2013 at 2:10 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> Robert Haas <robertmhaas@gmail.com> writes:
>>> Well, returning /tmp on Windows is just stupid.  I don't see why we
>>> should feel bad about changing that.  A bug is a bug.

>> What I was suggesting was we should take out the pgunixsocket fallback,
>> not make it even more complicated.  That probably implies that we need
>> still another accessor function to get the socket path.

> Well, I guess.  I have a hard time seeing whatever rejiggering we want
> to do in master as a reason not to back-patch that fix, though.

I guess as long as the pgunixsocket thing is in there, it makes sense
to substitute DefaultHost for it on Windows, but are we sure that's
something to back-patch?

Right now, as I was saying, PQhost is in some gray area where it's not too
clear what its charter is.  It's not "what was the host parameter", for
sure, but we haven't tried to make it an accurate description of the
connection either.  It's a bit less accurate on Windows than elsewhere,
but do we want to risk breaking anything to only partially resolve that?

More generally, if we do go over in 9.4 to the position that PQhost
reports the host parameter and nothing but, I'm not sure that introducing
a third behavior into the back branches is something that anybody will
thank us for.
        regards, tom lane



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Heikki Linnakangas
Дата:
Сообщение: Re: preserving forensic information when we freeze
Следующее
От: Kevin Grittner
Дата:
Сообщение: Re: ANALYZE sampling is too good