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