Sorry for the delay in responding to you. On Mon, Feb 11, 2013 at 6:03 AM, Phil Sorber <p...@omniti.com> wrote: > On Fri, Feb 8, 2013 at 1:07 PM, Phil Sorber <p...@omniti.com> wrote: >> On Fri, Feb 8, 2013 at 12:46 PM, Fujii Masao <masao.fu...@gmail.com> wrote: >>> No maybe. But I think that all the client commands should follow the >>> same rule. Otherwise a user would get confused when specifying >>> options. >> >> I would consider the rest of the apps using it as a consensus. I will >> make sure it aligns in behavior. >> > > I've done as you suggested, and made sure they align with other > command line utils. What I have found is that dbname is passed > (almost) last in the param array so that it clobbers all previous > values. I have made this patch as minimal as possible basing it off of > master and not off of my previous attempt. For the record I still like > the overall design of my previous attempt better, but I have not > included a new version based on that here so as not to confuse the > issue, however I would gladly do so upon request. > > Updated patch attached.
Thanks! The patch basically looks good to me. I updated the patch against current master and fixed some problems: - Handle the hostaddr in the connection string properly. - Remove the character 'V' from the third argument of getopt_long(). - Handle the error cases of PQconninfoParse() and PQconndefaults(). - etc... Please see the attached patch. Regards, -- Fujii Masao
pg_isready_con_str_v5.patch
Description: Binary data
-- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
