Re: [PATCH] psql: add \dcs to list all constraints - Mailing list pgsql-hackers

Thanks for your comments!

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

As you mentioned, there are already meta-command names such as
\dc, \dC, and \dconfig, so I wanted \dcs to be as distinct as possible.
That is why I formed it using the first letters of each syllable.

That said, I do not have a strong preference for \dcs, so I think
it is perfectly fine to change it to \dcn.


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

Regarding the suggestion to use uppercase letters for add-on filters,
I agree that this makes it easier to distinguish between the base
meta-command name and the filter options. However, as you pointed out,
there is not much precedent for this.

For example, I used \df as a reference, which has add-on filters
like this:

    \df[anptw][Sx+]...

Currently, \dcs also uses lowercase letters, but I would be open to
switching to uppercase if that is acceptable. (It might also be worth
considering changing \df to uppercase at some point.)


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

I understand that type constraints are constraints within the domain,
but since a dedicated meta command (\dD) already existed, they were
excluded from \dcs. \dD displays check constraints, etc., as shown below.

I understand that type constraints are constraints within domains.
Since there is already a dedicated meta-command (\dD) for domains,
I initially excluded them from \dcs.
As shown below, \dD already displays check constraints and related
information:

# \dD
                        List of domains
 Schema | Name | Type | Collation | Nullable | Default | Check
--------+------+------+-----------+----------+---------+-------

At first, I thought it would be better to avoid this because it
overlaps with \dD, but now I feel like it's okay to include it if
\dcs is a command that covers all constraints.
Is it okay to include it in \dcs?

At first, I thought it would be better to avoid overlapping with
\dD. However, I am now thinking that it might be acceptable to
include them if \dcs is meant to be a command that covers all constraints.

Would it be okay to include domain-related constraints in \dcs?


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

There are different possible opinions about the column order in \dcs.
I considered two main approaches: listing constraints by table, or
listing them by constraint name.
In the current implementation, I chose the latter, based on the assumption
that the user's primary interest in this command is the constraint name.

For example, although the \di command can display indexes on a per-table
basis, it primarily presents them as a list organized by index name.
The Schema column is followed by the index name, and the output is sorted
by that name, as shown below:

# \di
                List of indexes
 Schema |   Name    | Type  |  Owner   | Table
--------+-----------+-------+----------+-------
 public | bar_pkey  | index | postgres | bar
 public | foo_pkey  | index | postgres | foo
 public | hoge_pkey | index | postgres | hoge
 public | temp_ind1 | index | postgres | bar
(4 rows)

I applied the same design principle to \dcs. Also, users can use the
\d command to view constraints on a table-by-table basis.
For that reason, I would like to keep the column order as it is.
What do you think?

Regards,

Tatsuro Yamada