Обсуждение: [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?

От
"David G. Johnston"
Дата:
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.
"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


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