\describe*

On 01/26/2018 02:11 AM, Corey Huinker wrote:

Some of the discussions about making psql more user friendly (more tab
completions help, exit, etc) got me thinking about other ways that psql
could be more friendly, and the one that comes to mind is our terse but
cryptic \d* commands.

I think it would be helpful and instructive to have corresponding
long-form describe commands. 

Take describing schemas. Is \dn intuitive? Not really. In hindsight, you
may think "yeah, a schema is a namespace", but you never guessed 'n' on
the first try, or the second.

At first blush, I support this idea.

Looking over exec_command_d() a bit, I think it's a bit of a stretch do
have each command handle a long form like this:

\describe table my_table
or
\describe table verbose my_table

because then each \d-variant has to account for objects named "table"
and "verbose" and that's a path to unhappiness.

We're already being verbose so we can easily require

\describe table table

for the first case, and if you move "verbose" to before the object, then
we can have

\describe verbose table verbose

So basically, the grammar would be "\describe [verbose] [system] object
name" instead of "\dXS[+] name" where X is the object.

One thing not addressed here is a long version of \ditvS+. Maybe
something like

\describe verbose system index, table, view <pattern>

But if we dash-separated them, then all of the strcmps would be in the
'e' subsection, and each one would just have to know it's long to short
translation, and call exec_command_d with the corresponding short command

describe => d
describe-verbose => d+
describe-aggregates-verbose => da+
describe-roles => du

-1

We could even presume the verbose flag in all cases (after all, the user
was being verbose...), which would also cut down on tab-completion
results, and we could check for interactive mode and display a message like

\describe-schemas (short: \dn+)

so that the person has the opportunity to learn the corresponding short
command.

-1 on this, too.

If we presume "verbose", we need to add a "terse". If the user is
interested in the short forms, they can issue a \? like everybody else.

In additional to aiding tab completion discovery of the commands (i.e.
typing "\desc" and then hitting tab, it would also make scripts a little
more self-documenting.

I always use long versions of options when writing scripts specifically
because they are self-documenting (see 0be22457d7) so I certainly
support this argument.

Note: I am not volunteering to implement any of this, but I'll happily
review it.
--
Vik Fearing +33 6 46 75 15 36
http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support

Corey Huinker wrote:

Some of the discussions about making psql more user friendly (more tab completions help, exit, etc) got me thinking about other ways that psql could be more friendly, and the one that comes to mind is our terse but cryptic \d* commands.

I think it would be helpful and instructive to have corresponding long-form describe commands.

Take describing schemas. Is \dn intuitive? Not really. In hindsight, you may think "yeah, a schema is a namespace", but you never guessed 'n' on the first try, or the second.

Looking over exec_command_d() a bit, I think it's a bit of a stretch do have each command handle a long form like this:

\describe table my_table
or
\describe table verbose my_table

because then each \d-variant has to account for objects named "table" and "verbose" and that's a path to unhappiness.

But if we dash-separated them, then all of the strcmps would be in the 'e' subsection, and each one would just have to know it's long to short translation, and call exec_command_d with the corresponding short command

describe => d
describe-verbose => d+
describe-aggregates-verbose => da+
describe-roles => du

We could even presume the verbose flag in all cases (after all, the user was being verbose...), which would also cut down on tab-completion results, and we could check for interactive mode and display a message like

\describe-schemas (short: \dn+)

so that the person has the opportunity to learn the corresponding short command.

In additional to aiding tab completion discovery of the commands (i.e. typing "\desc" and then hitting tab, it would also make scripts a little more self-documenting.

Thoughts?

I'm somewhat -1 on this.

It would be about as hard to memorize \describe-schemas as it is to memorize \dn:
You'd have to remember that it is "-" and not "_", that it is "describe", not "desc"
and that it is "schemas", not "schema".

Moreover, it would be as awkward to have
\describe-schemas public
as it would be to list all schemas with
\describe-schema

But my strongest criticism is that the \d* commands are for interactive use,
and who wants to type in a long string like that? The beginner won't be able to
guess the correct command, and the experienced user would refuse to use it.

Having said all that, I can imagine that having \desc and \describe as an
alternative to \d would help beginners who come e.g. from Oracle,
but that would mean a change of the current behavior:

test=> \describe
List of foreign servers
Name | Owner | Foreign-data wrapper
--------+----------+----------------------
oracle | postgres | oracle_fdw
(1 row)

This is because \des lists foreign servers, and the rest of the command is ignored.

Yours,
Laurenz Albe

On Thu, Jan 25, 2018 at 08:11:00PM -0500, Corey Huinker wrote:

Some of the discussions about making psql more user friendly (more
tab completions help, exit, etc) got me thinking about other ways
that psql could be more friendly, and the one that comes to mind is
our terse but cryptic \d* commands.

They are indeed terse and cryptic, and what's worse, they're not
available to clients other than psql, so I propose that we do what at
least MySQL, Oracle, and DB2 do and implement DESCRIBE as its own
command.

Especially handy would be a variant DESCRIBE CREATE, which would do
what it says on the label in a copy-and-paste-able form, but that's
not strictly necessary for the first cut.

Best,
David.
--
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

On 01/26/2018 03:49 PM, David Fetter wrote:> They are indeed terse and
cryptic, and what's worse, they're not

available to clients other than psql, so I propose that we do what at
least MySQL, Oracle, and DB2 do and implement DESCRIBE as its own
command.

Especially handy would be a variant DESCRIBE CREATE, which would do
what it says on the label in a copy-and-paste-able form, but that's
not strictly necessary for the first cut.

I am not fan of this since I like how easy it is to explain to beginners
that all backslash commands are processed by the client while everything
else is handled by the server. Yes, "help" is an exception, but nobody
really needs to know about that command.

As for the actually proposal I do not care strongly either way. The \d
commands are a bit cryptic and unfriendly to the occasional user, but I
am not sure that having two ways to do it would be better.

Andreas

On 01/26/2018 03:49 PM, David Fetter wrote:

I propose that we do what at least MySQL, Oracle, and DB2 do and
implement DESCRIBE as its own command.

Hard pass.
--
Vik Fearing +33 6 46 75 15 36
http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support

It would be about as hard to memorize \describe-schemas as it is to
memorize \dn:
You'd have to remember that it is "-" and not "_", that it is "describe",
not "desc"
and that it is "schemas", not "schema".

You wouldn't memorize them. You'd discover them with tab completion.

Type "\d<tab>" and you'll see
\d \dA \dc \dd \ddp \des \deu \df \dFd \dFt \di \dL \dn \d0 \drds \dS \dT
\dv \dy
\da \db \dC \dD \dE \det \dew \dF \dFp \dg \dl \dm \do \dp \ds \dt \du
\dx

which is more heat than light. Yes, those are all the possibilites, but I,
Joe Newguy, want to list schemas, and \ds and \dS look like the good
guesses, neither of which is the right answer. If, with this feature, I
typed \desc<tab>, I might see:

\describe \describe-functions \describe-schemas \describe-tables
...

So my voyage of discovery would have completed with having typed
"\desc<tab>-sc<tab>" and if we add a note to interactive mode, I'd be shown
the hint that \dn is the shortcut for that just above the list of schemas.

On Fri, Jan 26, 2018 at 04:28:24PM +0100, Vik Fearing wrote:

On 01/26/2018 03:49 PM, David Fetter wrote:

I propose that we do what at least MySQL, Oracle, and DB2 do and
implement DESCRIBE as its own command.

Hard pass.

Would you be so kind as to expand on this? "Pass" might indicate a
lack of interest in doing the work, but "hard pass" seems to indicate
that you have reasons the work should not be done. Have I interpreted
this correctly?

Best,
David.
--
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

On 01/27/2018 05:39 PM, David Fetter wrote:

On Fri, Jan 26, 2018 at 04:28:24PM +0100, Vik Fearing wrote:

On 01/26/2018 03:49 PM, David Fetter wrote:

I propose that we do what at least MySQL, Oracle, and DB2 do and
implement DESCRIBE as its own command.

Hard pass.

Would you be so kind as to expand on this? "Pass" might indicate a
lack of interest in doing the work, but "hard pass" seems to indicate
that you have reasons the work should not be done. Have I interpreted
this correctly?

Andreas said it quite well. I don't like having client commands look
like server commands. I don't mind exceptions for "help" and "quit",
but I see no reason for anything more.
--
Vik Fearing +33 6 46 75 15 36
http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support

On Sat, Jan 27, 2018 at 10:54:07PM +0100, Vik Fearing wrote:

On 01/27/2018 05:39 PM, David Fetter wrote:

On Fri, Jan 26, 2018 at 04:28:24PM +0100, Vik Fearing wrote:

On 01/26/2018 03:49 PM, David Fetter wrote:

I propose that we do what at least MySQL, Oracle, and DB2 do and
implement DESCRIBE as its own command.

Hard pass.

Would you be so kind as to expand on this? "Pass" might indicate a
lack of interest in doing the work, but "hard pass" seems to indicate
that you have reasons the work should not be done. Have I interpreted
this correctly?

Andreas said it quite well. I don't like having client commands look
like server commands. I don't mind exceptions for "help" and "quit",
but I see no reason for anything more.

I did not propose a client command mimicking a server command. I
thought I made that clear by mentioning that the \ commands are
unavailable to clients other than psql, and offering an alternative.

What I propose is in fact a server command, which at least three of
the other popular RDBMSs already have.

Best,
David.
--
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

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. We would most likely want them implemented
the same, to avoid needless complexity.

I think people are more ok with \describe (with the backslash), which seems
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.

But \describe gives a hint that it's different with the \, so it might be
fine.

Overall I agree with your idea: the \d* commands are cryptic and a longhand
form would help people learning.

Best,
Ryan

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 seems
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.

Best,
David.
--
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

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
understandable
- save experienced users that 0.22 seconds where they try to remember what
\dFpS+ means or which command lists user mappings.

DESIGN CHOICES:

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
\dn.

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.

NOTES:

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
read.

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
\df exp
\d psql_serial_tab_id_seq

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
156 \d
2 \d'
1 \d*',
157 \d+
1 \d{4})',
1 \da
2 \d+):([a-zA-Z0-9+/=]+)\$([a-zA-Z0-9+=/]+):([a-zA-Z0-9+/=]+)',
4 \des
8 \des+
1 \det+
4 \deu
6 \deu+
1 \dew
14 \dew+
21 \df
1 \dfn
1 \dfp
4 \dp
4 \dRp
6 \dRp+
2 \dRs
3 \dRs+
2 \dt

On Mon, Jan 29, 2018 at 9:56 AM David Fetter <david@fetter.org> wrote:

Hi,

On 2019-01-24 20:37:48 -0500, Corey Huinker wrote:

Attached is a patch to add verbose \describe commands to compliment our
existing but slightly cryptic family of \d commands.

Given that this patch has been added to the last commitfest for v12, I
think we should mark it as targeting 13, so it can be skipped over by
people looking to get things into v12. Even leaving fairness aside, I
don't think it's likely to be ready quickly enough...

Greetings,

Andres Freund

Given that this patch has been added to the last commitfest for v12, I
think we should mark it as targeting 13, so it can be skipped over by
people looking to get things into v12. Even leaving fairness aside, I
don't think it's likely to be ready quickly enough...

Obviously this patch is nowhere near the importance of most patches slated
for v12, but I would hope it can be considered, time permitting.

The size of the patch may look large (1036 lines), but 650+ of that is pure
documentation changes, ~50 lines of added autocomplete strings, ~140 lines
are added TailMatches calls (one per new autocomplete string), and what
remains is strncmp() calls to match those same strings, so it's pretty mild
in terms of impact.

Hi,

On 2019-02-23 19:14:27 -0500, Corey Huinker wrote:

Given that this patch has been added to the last commitfest for v12, I
think we should mark it as targeting 13, so it can be skipped over by
people looking to get things into v12. Even leaving fairness aside, I
don't think it's likely to be ready quickly enough...

Obviously this patch is nowhere near the importance of most patches slated
for v12, but I would hope it can be considered, time permitting.

The size of the patch may look large (1036 lines), but 650+ of that is pure
documentation changes, ~50 lines of added autocomplete strings, ~140 lines
are added TailMatches calls (one per new autocomplete string), and what
remains is strncmp() calls to match those same strings, so it's pretty mild
in terms of impact.

Sure, but it was late, and we have far more patches than we can deal
with. Many of them much much older than this.

Greetings,

Andres Freund

On Sat, Feb 23, 2019 at 7:19 PM Andres Freund <andres@anarazel.de> wrote:

Sure, but it was late, and we have far more patches than we can deal
with. Many of them much much older than this.

More importantly, at least in my opinion, is that this is one of those
questions that people tend to have very strong feelings about. Doing
something at the last minute risks people not feeling that they had an
adequate time to express those feelings before something got shipped.
Not everybody reads this list every day, or tests every new commit as
soon as it goes into the tree.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

The following review has been posted through the commitfest application:
make installcheck-world: not tested
Implements feature: not tested
Spec compliant: not tested
Documentation: not tested

Thanks for the patch, I have reviewed the patch and have some comments about the patch. The review includes the testing of the patch along with some code review.

Here are my testings results,

- Tab completion for \descibe-verbose.
I know that \d+ tab completion is also not there, but I think we must have tab completion for \descibe-verbose.

postgres=# \describe-
\describe-extension \describe-replication-publication \describe-user-mapping
\describe-foreign-data-wrapper \describe-replication-subscription \describe-view
\describe-foreign-server \describe-role \describe-window-function
\describe-foreign-table \describe-rule
...

- Error message in each command.
There is an error message after each command, here is the example.
postgres=# \describe
List of relations
Schema | Name | Type | Owner
--------+------+-------+---------
public | foo | table | vagrant

(1 row)
Invalid command \describe. Try \? for help.

I think this status is causing the problem.

+                                                               /* standard listing of interesting things */
+                                                               success = listTables("tvmsE", NULL, show_verbose, show_system);
+                                               }
+                                               status = PSQL_CMD_UNKNOWN;

- Confusion about \desc and \desC
There is confusion while running the \desc command. I know the problem, but the user may confuse by this.
postgres=# \desC
List of foreign servers
Name | Owner | Foreign-data wrapper
------+-------+----------------------
(0 rows)

postgres=# \desc
Invalid command \desc. Try \? for help.

- Auto-completion of commands.
There is some more confusion in the completion of commands.

This command shows List of aggregates.
postgres=# \describe-aggregate-function
List of aggregate functions
Schema | Name | Result data type | Argument data types | Description
--------+------+------------------+---------------------+-------------
(0 rows)

This command shows a list of relation "\d"
postgres=# \describe-aggregatE-function
List of relations
Schema | Name | Type | Owner
--------+------+-------+---------
public | foo | table | vagrant
(1 row)

This command also shows a list of relations "\d".
postgres=# \describe-aggr
List of relations
Schema | Name | Type | Owner
--------+------+-------+---------
public | foo | table | vagrant
(1 row)

This command shows error messages.
postgres=# \descr
Invalid command \descr. Try \? for help.

...

Code review.
-------------

I have done a brief code review except for the documentation code. I don't like this code

if (cmd_match(cmd,"describe-aggregate-function"))
success = describeAggregates(pattern, show_verbose, show_system);
else if (cmd_match(cmd, "describe-access-method"))
success = describeAccessMethods(pattern, show_verbose);
else if (cmd_match(cmd, "describe-tablespace"))
success = describeTablespaces(pattern, show_verbose);
else if (cmd_match(cmd, "describe-conversion"))
success = listConversions(pattern, show_verbose, show_system);
else if (cmd_match(cmd, "describe-cast"))
success = listCasts(pattern, show_verbose

This can be achieved with the list/array/hash table, so I have changed that code in the attached patch just for a sample if you want I can do that for whole code.

--
Ibrar Ahmed

The new status of this patch is: Waiting on Author

Hi Corey,

Here is the modified patch (sample).

On Mon, Mar 4, 2019 at 7:02 PM Ibrar Ahmed <ibrar.ahmad@gmail.com> wrote:

The following review has been posted through the commitfest application:
make installcheck-world: not tested
Implements feature: not tested
Spec compliant: not tested
Documentation: not tested

Thanks for the patch, I have reviewed the patch and have some comments
about the patch. The review includes the testing of the patch along with
some code review.

Here are my testings results,

- Tab completion for \descibe-verbose.
I know that \d+ tab completion is also not there, but I think we must have
tab completion for \descibe-verbose.

postgres=# \describe-
\describe-extension
\describe-replication-publication \describe-user-mapping
\describe-foreign-data-wrapper
\describe-replication-subscription \describe-view
\describe-foreign-server \describe-role
\describe-window-function
\describe-foreign-table \describe-rule
...

- Error message in each command.
There is an error message after each command, here is the example.
postgres=# \describe
List of relations
Schema | Name | Type | Owner
--------+------+-------+---------
public | foo | table | vagrant

(1 row)
Invalid command \describe. Try \? for help.

I think this status is causing the problem.

+                                                               /*
standard listing of interesting things */
+                                                               success =
listTables("tvmsE", NULL, show_verbose, show_system);
+                                               }
+                                               status = PSQL_CMD_UNKNOWN;

- Confusion about \desc and \desC
There is confusion while running the \desc command. I know the problem,
but the user may confuse by this.
postgres=# \desC
List of foreign servers
Name | Owner | Foreign-data wrapper
------+-------+----------------------
(0 rows)

postgres=# \desc
Invalid command \desc. Try \? for help.

- Auto-completion of commands.
There is some more confusion in the completion of commands.

This command shows List of aggregates.
postgres=# \describe-aggregate-function
List of aggregate functions
Schema | Name | Result data type | Argument data types | Description
--------+------+------------------+---------------------+-------------
(0 rows)

This command shows a list of relation "\d"
postgres=# \describe-aggregatE-function
List of relations
Schema | Name | Type | Owner
--------+------+-------+---------
public | foo | table | vagrant
(1 row)

This command also shows a list of relations "\d".
postgres=# \describe-aggr
List of relations
Schema | Name | Type | Owner
--------+------+-------+---------
public | foo | table | vagrant
(1 row)

This command shows error messages.
postgres=# \descr
Invalid command \descr. Try \? for help.

...

Code review.
-------------

I have done a brief code review except for the documentation code. I don't
like this code

if (cmd_match(cmd,"describe-aggregate-function"))

success = describeAggregates(pattern, show_verbose, show_system);
else if (cmd_match(cmd,
"describe-access-method"))
success = describeAccessMethods(pattern,
show_verbose);
else if (cmd_match(cmd,
"describe-tablespace"))
success = describeTablespaces(pattern,
show_verbose);
else if (cmd_match(cmd,
"describe-conversion"))
success = listConversions(pattern,
show_verbose, show_system);
else if (cmd_match(cmd, "describe-cast"))
success = listCasts(pattern, show_verbose

This can be achieved with the list/array/hash table, so I have changed
that code in the attached patch just for a sample if you want I can do that
for whole code.

--
Ibrar Ahmed

The new status of this patch is: Waiting on Author

--
Ibrar Ahmed

- Tab completion for \descibe-verbose.
I know that \d+ tab completion is also not there, but I think we must
have tab completion for \descibe-verbose.

postgres=# \describe-
\describe-extension
\describe-replication-publication \describe-user-mapping
\describe-foreign-data-wrapper
\describe-replication-subscription \describe-view
\describe-foreign-server \describe-role
\describe-window-function
\describe-foreign-table \describe-rule
...

I just confirmed that there isn't tab completion for the existing S/+
options, so it's hard to justify them for the equivalent verbose suffixes.

(1 row)

Invalid command \describe. Try \? for help.

I think this status is causing the problem.

+                                                               /*
standard listing of interesting things */
+                                                               success =
listTables("tvmsE", NULL, show_verbose, show_system);
+                                               }
+                                               status = PSQL_CMD_UNKNOWN;

I'll look into this, thanks!

- Confusion about \desc and \desC

There is confusion while running the \desc command. I know the problem,
but the user may confuse by this.
postgres=# \desC
List of foreign servers
Name | Owner | Foreign-data wrapper
------+-------+----------------------
(0 rows)

postgres=# \desc
Invalid command \desc. Try \? for help.

- Auto-completion of commands.
There is some more confusion in the completion of commands.

This command shows List of aggregates.
postgres=# \describe-aggregate-function
List of aggregate functions
Schema | Name | Result data type | Argument data types | Description
--------+------+------------------+---------------------+-------------
(0 rows)

This command shows a list of relation "\d"
postgres=# \describe-aggregatE-function
List of relations
Schema | Name | Type | Owner
--------+------+-------+---------
public | foo | table | vagrant
(1 row)

This command also shows a list of relations "\d".
postgres=# \describe-aggr
List of relations
Schema | Name | Type | Owner
--------+------+-------+---------
public | foo | table | vagrant
(1 row)

This command shows error messages.
postgres=# \descr
Invalid command \descr. Try \? for help.

I will look into it.

I have done a brief code review except for the documentation code. I
don't like this code

if (cmd_match(cmd,"describe-aggregate-function"))

success = describeAggregates(pattern, show_verbose, show_system);
else if (cmd_match(cmd,
"describe-access-method"))
success = describeAccessMethods(pattern,
show_verbose);
else if (cmd_match(cmd,
"describe-tablespace"))
success = describeTablespaces(pattern,
show_verbose);
else if (cmd_match(cmd,
"describe-conversion"))
success = listConversions(pattern,
show_verbose, show_system);
else if (cmd_match(cmd, "describe-cast"))
success = listCasts(pattern, show_verbose

This can be achieved with the list/array/hash table, so I have changed
that code in the attached patch just for a sample if you want I can do that
for whole code.

There's some problems with a hash table. The function signatures vary quite
a lot, and some require additional psql_scan_slash_options to be called.
The hash option, if implemented, probably should be expanded to all slash
commands, at which point maybe it belongs in psqlscanslash.l...