Re: Add psql command to list constraints

From: "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com>
To: Tatsuro Yamada <tatsuro(dot)yamada(dot)tf(at)nttcom(dot)co(dot)jp>
Cc: Justin Pryzby <pryzby(at)telsasoft(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Add psql command to list constraints
Date: 2021-11-16 02:08:56
Message-ID: CAKFQuwYLRJ-Oatk2CXETAA1XSV9d9de60pkntVtQrGougWFJaQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Mon, Nov 15, 2021 at 5:23 PM Tatsuro Yamada <
tatsuro(dot)yamada(dot)tf(at)nttcom(dot)co(dot)jp> wrote:

>
> > I'm not confident that if I would use this, so let's wait to see if
> someone
> > else wants to give a +1.
>
> Okay, but you agree that there are DBAs and users who want to see the
> list of constraints, I think.
>

My opinion is this doesn't exist because there isn't any demand for it.

> For example, it will be easier to understand how many foreign key
> constraints are in the DB.

That isn't a very compelling metric. Metrics also don't seem to be the
primary motivation for the psql \d commands. I envision them mostly useful
when writing a query and wanting a query refresher as to what is
valid/available. In that context looking at constraints in the context of
a single table makes sense. Looking at all constraints is considerably
less so. Especially since constraints mostly impact insert queries and
those only affect a single table.

If the only motivation for this is "feature completion" - since we have so
many other \d commands already implemented - I say we should pass.

David J.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Bharath Rupireddy 2021-11-16 02:30:40 Re: Logical Replication - improve error message while adding tables to the publication in check_publication_add_relation
Previous Message Justin Pryzby 2021-11-16 02:02:15 Re: Add psql command to list constraints