On Tue, Nov 19, 2013 at 1:10 PM, Fujii Masao <masao.fu...@gmail.com> wrote: > On Tue, Nov 19, 2013 at 11:51 PM, Robert Haas <robertmh...@gmail.com> wrote: >> On Fri, Nov 15, 2013 at 9:01 PM, FabrÃzio de Royes Mello >> <fabriziome...@gmail.com> wrote: >>> On Wed, Nov 13, 2013 at 9:37 PM, Josh Berkus <j...@agliodbs.com> wrote: >>>> handyrep@john:~/handyrep$ pg_isready --version >>>> pg_isready (PostgreSQL) 9.3.1 >>>> >>>> handyrep@john:~/handyrep$ pg_isready -h john -p 5432 -U postgres -d >>>> postgres -q >>>> pg_isready: missing "=" after "postgres" in connection info string >>>> >>>> handyrep@john:~/handyrep$ pg_isready --host=john --port=5432 >>>> --user=postgres --dbname=postgres >>>> pg_isready: missing "=" after "postgres" in connection info string >>>> >>>> handyrep@john:~/handyrep$ pg_isready -h john -p 5432 -U postgres >>>> john:5432 - accepting connections >>>> >>>> so apparently the -d option: >>>> >>>> a) doesn't work, and >>>> b) doesn't do anything >>>> >>>> I suggest simply removing it from the utility. >>>> >>>> I'll note that the -U option doesn't appear to do anything relevant >>>> either, but at least it doesn't error unnecessarily: >>>> >>>> handyrep@john:~/handyrep$ pg_isready -h john -p 5432 -U no_such_user >>>> john:5432 - accepting connections >>>> >>> >>> The attached patch fix it. >> >> Well, there still seem to be some problems. >> >> [rhaas pgsql]$ src/bin/scripts/pg_isready -d host=sgdasasg >> /tmp:5432 - no attempt >> >> I added some debugging instrumentation and it looks like there's a >> problem with this code: >> >> if (strcmp(def->keyword, "hostaddr") == 0 || >> strcmp(def->keyword, "host") == 0) >> >> The problem is that we end up executing the code contained in that >> block twice, once for host and once for hostaddr. Thus: >> >> [rhaas pgsql]$ src/bin/scripts/pg_isready -d host=sgdasasg >> def->keyword=host pghost_str=sgdasasg >> def->keyword=hostaddr pghost_str=/tmp >> def->keyword=port pgport_str=5432 >> /tmp:5432 - no attempt >> >> Oops. >> >> Nevertheless, that's kind of a separate problem, so we could address >> in a separate commit. But even ignoring that, this still isn't right: >> according to the fine documentation, -d will be expanded not only if >> it contains an =, but also if it starts with a valid URI prefix. This >> would break that documented behavior. >> >> http://www.postgresql.org/docs/9.3/static/app-pg-isready.html > > Attached is the updated version of the patch. Is there any other bug?
Not that I can see, but it's not very future-proof. If libpq changes its idea of what will provoke database-name expansion, this will again be broken. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers