Re: PSQL schema "describe" \dn is not escaping quotes

From: Peter Smith <smithpb2250(at)gmail(dot)com>
To: surya poondla <suryapoondla4(at)gmail(dot)com>
Cc: PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, "jiaoshuntian(at)gmail(dot)com" <jiaoshuntian(at)gmail(dot)com>, "nishant(dot)sharma(at)enterprisedb(dot)com" <nishant(dot)sharma(at)enterprisedb(dot)com>, "jim(dot)jones(at)uni-muenster(dot)de" <jim(dot)jones(at)uni-muenster(dot)de>, "niushiji(at)gmail(dot)com" <niushiji(at)gmail(dot)com>
Subject: Re: PSQL schema "describe" \dn is not escaping quotes
Date: 2026-09-02 02:42:06
Message-ID: CAHut+PuZnCKdOKbQo_dyr0Jq79S6GnPYYOiTmVRBM6KPAaCaTg@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, Sep 2, 2026 at 9:48 AM surya poondla <suryapoondla4(at)gmail(dot)com> wrote:
>
> Hi Peter,
>
> Thanks for the patch. Nice review comments.
>
> I applied v3 on master and did some testing of my own. A few observations.
>
> 1) The patch fixes more than the reported case, which I think is worth calling out in the commit message. Because the old code compared
> n.nspname against the raw pattern text, the footer was silently missing for *any* double-quoted pattern, not just ones containing an embedded single quote:
>
> -- unpatched
> test=# \dn sch_a
> List of schemas
> Name | Owner
> -------+----------
> sch_a | postgres
> Included in publications:
> "pub_a"
>
> test=# \dn "sch_a"
> List of schemas
> Name | Owner
> -------+----------
> sch_a | postgres
> (1 row) <-- footer silently missing
>
>
> FWIW I checked describe.c for other places where a user-supplied pattern is interpolated into query text, and this is the only one
> every other use of 'pattern' is either a pg_log_error() message or goes through validateSQLNamePattern().
>
> 2) I'm less sure about switching this query to pattern matching. processSQLNamePattern() turns it into a regex match, so it can now
> match several schemas, but the footer belongs to the whole table rather than to any one row:
>
> -- v3
> test=# \dn sch*
> List of schemas
> Name | Owner
> -------+----------
> sch_a | postgres
> sch_b | postgres
> Included in publications:
> "pub_a"
> "pub_b"
>
> There's no way to tell which publication goes with which schema, and with "\dn *" you get every schema publication in the database lumped
> into one footer.

Good catch. I see your point. When I tried the similar scenaro for
tables it clearly separated them, so I am working to make the describe
schemas behave like that. Will post a new patch when ready.

CREATE TABLE t1_a(a int);
CREATE TABLE t1_b(a int);
CREATE TABLE t1_c(a int);
CREATE PUBLICATION pub_a FOR TABLE t1_a;
CREATE PUBLICATION pub_b FOR TABLE t1_b;

test_pub=# \d t1_a
Table "public.t1_a"
Column | Type | Collation | Nullable | Default
--------+---------+-----------+----------+---------
a | integer | | |
Included in publications:
"pub_a"

test_pub=# \d t1_*
Table "public.t1_a"
Column | Type | Collation | Nullable | Default
--------+---------+-----------+----------+---------
a | integer | | |
Included in publications:
"pub_a"

Table "public.t1_b"
Column | Type | Collation | Nullable | Default
--------+---------+-----------+----------+---------
a | integer | | |
Included in publications:
"pub_b"

Table "public.t1_c"
Column | Type | Collation | Nullable | Default
--------+---------+-----------+----------+---------
a | integer | | |

======
Kind Regards,
Peter Smith.
Fujitsu Australia

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2026-09-02 03:03:07 Re: xid_wraparound/002_limits.pl might fail due to transient warning
Previous Message jian he 2026-09-02 02:38:22 Re: UPDATE run check constraints for affected columns only