Re: [PATCH] psql: add \dcs to list all constraints

Tatsuro Yamada <yamatattsu(at)gmail(dot)com> writes:
> I noticed that when the "+" (verbose option) is not used, the table name is
> not needed. In that case, joining the pg_class table is unnecessary.

A couple of drive-by comments:

* I don't like the name "\dcs": "cs" is a very strange choice of
abbreviation for "constraint". Now, psql already has "\dc" and
"\dconfig", so our options are pretty limited, but I think that
"\dcn" would be least surprising. It's typical to drop vowels
when abbreviating, so dropping the "o" makes sense (and we'd be
too close to "\dconfig" if we don't). But I don't see the
argument for skipping "n" to seize on the next consonant "s".

* You might do well to use upper-case letters for add-on
filters (that is, "N" not "n" for not-null, etc). This isn't
really a convention we've used elsewhere, except for the case
of "S" for "system" in some commands. But I think it's too
hard to tell the base command name from the filter add-ons
without some typographic help like that. Also, with this
being next door to "\dconfig" which is often abbreviated as
"\dcon", it seems like "\dcsn" or "\dcnn" would look too much
like typos for that.

* What about constraints on types (primarily, domain check
constraints)? I'm not insisting that this patch support that,
but it'd be smart to take some thought now for how a future
command for that could be wedged into the command namespace.

* Not sure about column order of the output:

Schema | Name | Definition | Table
--------+----------------------------+----------------------+-------

I find that just really odd. Why not "Schema | Table | Name |
Definition"? This also touches on whether we really need a "+" form
at all, rather than just always printing all four columns, because
I'm not sure I buy that you can infer the table name from the
constraint name. Yes, it probably works okay for constraints that
were given default names, but for user-specified names maybe not so
much. There's also the point that we don't guarantee that constraint
names are unique per-schema, only per-table.

regards, tom lane