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

From: Jim Jones <jim(dot)jones(at)uni-muenster(dot)de>
To: Tatsuro Yamada <yamatattsu(at)gmail(dot)com>
Cc: pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>, Álvaro Herrera <alvherre(at)kurilemu(dot)de>
Subject: Re: [PATCH] psql: add \dcs to list all constraints
Date: 2026-01-12 15:17:31
Message-ID: c13555a7-54dd-4ebe-aa79-65a2e5c268f8@uni-muenster.de
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 12/01/2026 06:39, Tatsuro Yamada wrote:
> Comments and suggestions are welcome.

Here a few comments to v2:

== listConstraints() ==

...

if (!showSystem && !pattern)
appendPQExpBufferStr(&buf,
"WHERE n.nspname <> 'pg_catalog' \n"
" AND n.nspname <> 'information_schema' \n");

if (!validateSQLNamePattern(&buf, pattern,
!showSystem && !pattern, false,
"n.nspname", "cst.conname", NULL,
"pg_catalog.pg_table_is_visible(cst.conrelid)",
NULL, 3))
{
termPQExpBuffer(&buf);
return false;
}

if (!showAllkinds)
{
appendPQExpBufferStr(&buf, " AND cst.contype in ("); <== here!

....

It looks like that a WHERE condition can be potentially added to the "if
(!showAllkinds)" block even if there is no WHERE clause at all. I'm not
sure if this path is even possible, but perhaps a more defensive
approach here wouldn't be a bad idea, e.g.

...
bool have_where = false;

if (!showSystem && !pattern)
{
appendPQExpBufferStr(&buf,
"WHERE n.nspname <> 'pg_catalog' \n"
" AND n.nspname <> 'information_schema' \n");
have_where = true;
}

if (!validateSQLNamePattern(&buf, pattern,
have_where, false,
"n.nspname", "cst.conname", NULL,
"pg_catalog.pg_table_is_visible(cst.conrelid)",
&have_where, 3))
{

if (!showAllkinds)
{
appendPQExpBuffer(&buf, " %s cst.contype in (",
have_where ? "AND" : "WHERE");
...

What do you think?

== Patch name ==

It'd be better if you format your patch name with the version upfront, e.g.

$ git format-patch -1 -v3

I've tried a few more edge cases and so far everything is working as
expected

postgres=# \set ECHO_HIDDEN on

postgres=# CREATE TABLE zoo (id int PRIMARY KEY, name text);
ALTER TABLE zoo ADD CONSTRAINT 🐘1 CHECK (name = '🐘');
CREATE TABLE
ALTER TABLE
postgres=# \dcs 🐘*
/******** QUERY *********/
SELECT n.nspname AS "Schema",
cst.conname AS "Name"
FROM pg_catalog.pg_constraint cst
JOIN pg_catalog.pg_namespace n ON n.oid = cst.connamespace
JOIN pg_catalog.pg_class c on c.oid = cst.conrelid
WHERE cst.conname OPERATOR(pg_catalog.~) '^(🐘.*)$' COLLATE
pg_catalog.default
AND pg_catalog.pg_table_is_visible(cst.conrelid)
ORDER BY 1, 2;
/************************/

List of constraints
Schema | Name
--------+------
public | 🐘1
(1 row)

postgres=# \dcs+ 🐘*
/******** QUERY *********/
SELECT n.nspname AS "Schema",
cst.conname AS "Name" ,
pg_catalog.pg_get_constraintdef(cst.oid) AS "Definition",
c.relname AS "Table"
FROM pg_catalog.pg_constraint cst
JOIN pg_catalog.pg_namespace n ON n.oid = cst.connamespace
JOIN pg_catalog.pg_class c on c.oid = cst.conrelid
WHERE cst.conname OPERATOR(pg_catalog.~) '^(🐘.*)$' COLLATE
pg_catalog.default
AND pg_catalog.pg_table_is_visible(cst.conrelid)
ORDER BY 1, 2, 4;
/************************/

List of constraints
Schema | Name | Definition | Table
--------+------+-----------------------------+-------
public | 🐘1 | CHECK ((name = '🐘'::text)) | zoo
(1 row)

postgres=# \dcs
/******** QUERY *********/
SELECT n.nspname AS "Schema",
cst.conname AS "Name"
FROM pg_catalog.pg_constraint cst
JOIN pg_catalog.pg_namespace n ON n.oid = cst.connamespace
JOIN pg_catalog.pg_class c on c.oid = cst.conrelid
WHERE n.nspname <> 'pg_catalog'
AND n.nspname <> 'information_schema'
AND pg_catalog.pg_table_is_visible(cst.conrelid)
ORDER BY 1, 2;
/************************/

List of constraints
Schema | Name
--------+-----------------
public | zoo_id_not_null
public | zoo_pkey
public | 🐘1
(3 rows)

Thanks

Best, Jim

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Greg Sabino Mullane 2026-01-12 15:23:11 Re: ALTER TABLE: warn when actions do not recurse to partitions
Previous Message Tom Lane 2026-01-12 15:05:47 Re: Maybe BF "timedout" failures are the client script's fault?