Thread: [GENERAL] psql: do/should we document that argument and option specificationorder doesn't matter?
[GENERAL] psql: do/should we document that argument and option specificationorder doesn't matter?
From
"David G. Johnston"
Date:
I don't know if this applies anywhere else but I just stumbled across the fact that our psql documentation is imprecise:
psql [option...] [dbname [username]]
It does matter that "dbname" precede username; and that it be present if username is specified. But otherwise the first one or two non-option words on the command line are taken to be those regardless of position, and any extra non-option words are ignored. Options can thus be specified before, after, or in between the dbname and username.
i.e., the following is valid:
psql [dbname] [option...] [# you can place username here but only if dbname is specified...]
Ubuntu Bash; 9.5 tested.
I'm not sure how one would actually document the above in a syntax specification without being overly verbose but there is no hint that I've found pertaining to the true behavior. Haven't played with any other of the supplied binaries; I stumbled across this because I was wrapping psql in specialized functions and was surprised that where I placed the "$@" and/or the "service=service-name" specification didn't seem to matter.
Is this some general Bash/Linux-ism that I've just never read about or realized until now?
David J.
Re: [GENERAL] psql: do/should we document that argument and option specification order doesn't matter?
From
Tom Lane
Date:
"David G. Johnston" <david.g.johnston@gmail.com> writes: > I don't know if this applies anywhere else but I just stumbled across the > fact that our psql documentation is imprecise: > https://www.postgresql.org/docs/current/static/app-psql.html > psql [option...] [dbname [username]] > It does matter that "dbname" precede username; and that it be present if > username is specified. But otherwise the first one or two non-option words > on the command line are taken to be those regardless of position, and any > extra non-option words are ignored. Options can thus be specified before, > after, or in between the dbname and username. This is, unfortunately, platform-specific. glibc's version of getopt_long() takes it upon itself to physically rearrange the argv list to make such cases work. On platforms where getopt_long() does not so blatantly exceed its authority, only the documented argument order will work. regards, tom lane
Re: [GENERAL] psql: do/should we document that argument and option specification order doesn't matter?
From
George Neuner
Date:
On Thu, 11 May 2017 16:15:43 -0700, "David G. Johnston" <david.g.johnston@gmail.com> wrote: >I don't know if this applies anywhere else but I just stumbled across the >fact that our psql documentation is imprecise: > >https://www.postgresql.org/docs/current/static/app-psql.html > >psql [option...] [dbname [username]] > >It does matter that "dbname" precede username; and that it be present if >username is specified. But otherwise the first one or two non-option words >on the command line are taken to be those regardless of position, and any >extra non-option words are ignored. Options can thus be specified before, >after, or in between the dbname and username. > >i.e., the following is valid: > >psql [dbname] [option...] [# you can place username here but only if dbname >is specified...] > >Ubuntu Bash; 9.5 tested. > >I'm not sure how one would actually document the above in a syntax >specification without being overly verbose but there is no hint that I've >found pertaining to the true behavior. Haven't played with any other of >the supplied binaries; I stumbled across this because I was wrapping psql >in specialized functions and was surprised that where I placed the "$@" >and/or the "service=service-name" specification didn't seem to matter. > >Is this some general Bash/Linux-ism that I've just never read about or >realized until now? The shell expands wildcards before passing them to the application, but argument handling is completely up to the application. psql maybe is more permissive regarding the order than it really needs to be. I think it would be far easier to change the program to enforce the documented order than to document the program's current behavior. The question is, do we really need to do it? If one adheres to the documented ordering, it works. And if the dbname and username both are passed as dashed options, there can't be any confusion at all. There is utility in the naked dbname, but perhaps it's time to lose the naked username? How many people actually use that syntax vs some other method: sudo, .pgpass, environment variables, etc. ? YMMV, George