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

From: Álvaro Herrera <alvherre(at)kurilemu(dot)de>
To: Tatsuro Yamada <yamatattsu(at)gmail(dot)com>
Cc: Chao Li <li(dot)evan(dot)chao(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Jim Jones <jim(dot)jones(at)uni-muenster(dot)de>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [PATCH] psql: add \dcs to list all constraints
Date: 2026-01-20 12:30:22
Message-ID: 202601201214.gl7w3td7dlfs@alvherre.pgsql
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 2026-Jan-20, Tatsuro Yamada wrote:

> The error in the query has been fixed, and the execution times were
> measured again.
> As a result, there was no significant difference in execution time
> between the two queries (see the attached test_result2.txt).
> When comparing the cost of the top node, the original query has a
> slightly lower cost, so I decided to keep it as is.

Yeah, these results match my own tests -- the query I proposed is a bit
slower. Not by a lot, but measurably so. (I did ran my disk full by
running pgbench with the two queries in separate files and the one
million constraints; temp files for sort are quite large. My query is
pretty consistently reported to be slower than the other anyway.)

> List of constraints
> Schema | Table | Type | Name
> --------+-------+-----------+----------------------------
> public | con_c | NOT NULL | con_c_primary_col_not_null
> public | con_c | PK | con_c_pkey
> public | con_p | CHECK | con_p_check_col_check
> public | con_p | EXCLUSION | con_p_exclusion
> public | con_p | FK | con_p_foreign_col_fkey
> public | con_p | NOT NULL | con_p_notnull_col_not_null
> public | con_p | NOT NULL | con_p_primary_col_not_null
> public | con_p | PK | con_p_pkey
> public | con_p | TRIGGER | con_p_trigger
> public | con_p | UNIQUE | con_p_unique_col_key
> (10 rows)
>
> What do you think?

Looks good. I think the constraint types ought to be lower-case and
fully spelled out, with not-null having an hyphen as discussed
elsewhere (though I couldn't find the reference), so
not-null
primary key
exclusion
check
foreign key
unique
trigger

I wonder if we should mark temporal constraints especially. (So
"temporal primary key", etc). Without thinking too much about it, my
impression is that it'd be useful.

I didn't look at the patch closer, apologies.

Thanks

--
Álvaro Herrera 48°01'N 7°57'E — https://www.EnterpriseDB.com/
Officer Krupke, what are we to do?
Gee, officer Krupke, Krup you! (West Side Story, "Gee, Officer Krupke")

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Ajit Awekar 2026-01-20 12:31:21 Re: Periodic authorization expiration checks using GoAway message
Previous Message Álvaro Herrera 2026-01-20 12:14:25 Re: Add IS_INDEX macro to brin and gist index