On Fri, Jan 25, 2013 at 11:20 AM, Fujii Masao <masao.fujii@gmail.com> wrote:
> On Fri, Jan 25, 2013 at 4:10 AM, Phil Sorber <phil@omniti.com> wrote:
>> On Thu, Jan 24, 2013 at 1:12 PM, Fujii Masao <masao.fujii@gmail.com> wrote:
>>> set_pglocale_pgservice() should be called?
>>>
>>> I think that the command name (i.e., pg_isready) should be given to
>>> PQpingParams() as fallback_application_name. Otherwise, the server
>>> by default uses "unknown" as the application name of pg_isready.
>>> It's undesirable.
>>>
>>> Why isn't the following message output only when invalid option is
>>> specified?
>>>
>>> Try \"%s --help\" for more information.
>>
>> I've updated the patch to address these three issues. Attached.
>>
>>>
>>> When the conninfo string including the hostname or port number is
>>> specified in -d option, pg_isready displays the wrong information
>>> as follows.
>>>
>>> $ pg_isready -d "port=9999"
>>> /tmp:5432 - no response
>>>
>>
>> This is what i asked about in my previous email about precedence of
>> the parameters. I can parse that with PQconninfoParse, but what are
>> the rules for merging both individual and conninfo params together?
>
> If I read conninfo_array_parse() correctly, PQpingParams() prefer the
> option which is set to its keyword array later.
It would be really nice to expose conninfo_array_parse() or some
wrapped version directly to a libpq consumer. Otherwise, I need to
recreate this behavior in pg_isready.c.
Thoughts on adding: PQconninfoOption *PQparamsParse(const char **keywords, const char
**values, char **errmsg, bool use_defaults, int expand_dbname)
or similar?
Or perhaps there is a better way to accomplish this that I am not aware of?
>
> Regards,
>
> --
> Fujii Masao