Re: [PATCH] pg_isready (was: [WIP] pg_ping utility) - Mailing list pgsql-hackers

From Phil Sorber
Subject Re: [PATCH] pg_isready (was: [WIP] pg_ping utility)
Date
Msg-id CADAkt-gQKRUVGPPrurh2kiSnsDP1kjSHAcAFEcc+Cty5Z1-SAQ@mail.gmail.com
Whole thread Raw
In response to Re: [PATCH] pg_isready (was: [WIP] pg_ping utility)  (Alvaro Herrera <alvherre@2ndquadrant.com>)
List pgsql-hackers
On Mon, Jan 28, 2013 at 1:12 PM, Alvaro Herrera
<alvherre@2ndquadrant.com> wrote:
> Phil Sorber escribió:
>> On Mon, Jan 28, 2013 at 11:20 AM, Fujii Masao <masao.fujii@gmail.com> wrote:
>> > Maybe. But I'm not inclined to add new libpq interface at this stage.
>> > Because we are in the last CommitFest and I'm not sure whether
>> > we have enough time to implement that. Instead, how about using
>> > both PQconninfoParse() and PQconndefaults() like uri-regress.c does?
>> > Or just remove that output message? At least I don't think that the
>> > information about host and port needs to be output. Which would make
>> > the code very simpler.
>>
>> I think that output is important as do others up thread. I think it'd
>> be simpler to just disable dbname's ability to double as conninfo. If
>> we are looking for easy, that is.
>>
>> I don't mind duplicating the behavior from conninfo_array_parse() or
>> uri-regress.c either. I can just put a comment that at some point in
>> the future we should add a libpq interface for it.
>
> I suggest duplicate the code for 9.3, and submit a patch to refactor
> into a new libpq function for CF2013-next.  If the patch is simple
> enough, we can consider putting it into 9.3.

Ok, sounds good to me.

>
> --
> Álvaro Herrera                http://www.2ndQuadrant.com/
> PostgreSQL Development, 24x7 Support, Training & Services



pgsql-hackers by date:

Previous
From: Alvaro Herrera
Date:
Subject: Re: [PATCH] pg_isready (was: [WIP] pg_ping utility)
Next
From: Tom Lane
Date:
Subject: Re: in-catalog Extension Scripts and Control parameters (templates?)