On Sun, Jan 27, 2013 at 2:38 PM, Phil Sorber <p...@omniti.com> wrote: > On Fri, Jan 25, 2013 at 11:20 AM, Fujii Masao <masao.fu...@gmail.com> wrote: >> On Fri, Jan 25, 2013 at 4:10 AM, Phil Sorber <p...@omniti.com> wrote: >>> On Thu, Jan 24, 2013 at 1:12 PM, Fujii Masao <masao.fu...@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? >
It would also be nice to be able to pass user_defaults to PQconninfoParse(). >> >> Regards, >> >> -- >> Fujii Masao -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
