On Mon, Jan 28, 2013 at 4:47 AM, Phil Sorber <p...@omniti.com> wrote: > 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?
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. 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
