|From:||Corey Huinker <corey(dot)huinker(at)gmail(dot)com>|
|To:||David Fetter <david(at)fetter(dot)org>|
|Cc:||Ryan Murphy <ryanfmurphy(at)gmail(dot)com>, Vik Fearing <vik(dot)fearing(at)2ndquadrant(dot)com>, pgsql-hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>|
|Views:||Raw Message | Whole Thread | Download mbox|
Attached is a patch to add verbose \describe commands to compliment our
existing but slightly cryptic family of \d commands.
The goals of this are:
- aid user discovery of \d-commands via tab completion
- make scripts and snippets slightly more self-documenting and
- save experienced users that 0.22 seconds where they try to remember what
\dFpS+ means or which command lists user mappings.
Every new command is of the form
\describe-some-system-object-type[-system][-verbose]. The -system suffix
stands in for the 'S' suffix and -verbose stands in for '+'.
New commands used the singular form, not plural.
Every new command has a direct analog \d-command, but the reverse is not
always true, especially when it comes to the commands that can specify
multiple object types. In those cases, there are multiple long versions
that correspond to several singular parameters (\describe-view,
\describe-materialized-view, \describe-index, etc) but no combinatorics
(i.e. no \describe-view-and-foreign-table).
There is a \describe-schema and \describe-namespace, both of which perform
There is a \describe-role but no \describe-user or \describe-database-role.
I chose \describe-privilege for \dp
I chose \describe-type for \dT instead of \describe-data-type.
The command \describe-aggregate-function is \dfa, whereas
\describe-aggregate is \da.
There is currently nothing stopping you from using the short form suffixes
on long form commands, but the reverse isn't true. For example, you can
type \describe-functionS+ and it'll work, but \df-verbose will not. I allow
this mostly because it would take work to prevent it.
Documentation XML was updated but not formatted to make the diff easier to
No regression cases were added. Currently our coverage of \d commands in
psql ifself is quite minimal:
~/src/postgres$ grep '\\d' src/test/regress/sql/psql.sql | sort | uniq
\copyright \dt arg1 \e arg1 arg2
but perhaps we could test it indirectly in these other areas:
~/src/postgres/src/test/regress/sql$ grep '\\d' * | sed -e 's/^.*\\d/\\d/g'
-e 's/ .*//g' | sort | uniq -c
On Mon, Jan 29, 2018 at 9:56 AM David Fetter <david(at)fetter(dot)org> wrote:
> On Mon, Jan 29, 2018 at 02:51:53PM +0000, Ryan Murphy wrote:
> > >
> > > >What I propose is in fact a server command, >which at least three of
> > > >the other popular RDBMSs already have.
> > >
> > Well to actually implement it, it would probably be a client command,
> > because that's what \d* are.
> Why should this command be silo'ed off to the psql client? If it's a
> server command, it's available to all clients, not just psql.
> > We would most likely want them implemented the same, to avoid
> > needless complexity.
> We could certainly have \d call DESCRIBE for later versions of the
> server. \ commands which call different SQL depending on server
> version have long been a standard practice.
> > I think people are more ok with \describe (with the backslash), which
> > like what you're suggesting anyway. I read Vik's "hard pass" as being on
> > having DESCRIBE which looks like an SQL command but would actually be
> > implemented on the client. This seems simpler at first but could cause
> > deep confusion later.
> If we implement \d as DESCRIBE for server versions as of when DESCRIBE
> is actually implemented, we've got wins all around.
> David Fetter <david(at)fetter(dot)org> http://fetter.org/
> Phone: +1 415 235 3778
> Remember to vote!
> Consider donating to Postgres: http://www.postgresql.org/about/donate
|Next Message||Jamison, Kirk||2019-01-25 02:31:57||RE: pg_upgrade: Pass -j down to vacuumdb|
|Previous Message||Nagaura, Ryohei||2019-01-25 01:00:42||RE: libpq debug log|