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

From: surya poondla <suryapoondla4(at)gmail(dot)com>
To: Peter Smith <smithpb2250(at)gmail(dot)com>
Cc: Steven Niu <niushiji(at)gmail(dot)com>, Ajin Cherian <itsajin(at)gmail(dot)com>, 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>
Subject: Re: PSQL schema "describe" \dn is not escaping quotes
Date: 2026-10-16 00:16:59
Message-ID: CAOVWO5rQ9QXc=s_4LUFG-xn5VtA469tN+0_ENQfGTFaEFPhgAQ@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi Peter,

Thanks for v8. Cutting it down to the minimal fix makes sense to me, and I
agree the redesign is best dropped.

v8 no longer applies to master since Tom's 294d2196c7a, which replaced the
printfPQExpBuffer() label line with addQueryComment(). The conflict is
trivial (keep addQueryComment() and your new query). With that resolved it
builds cleanly, make check passes, and names with embedded ', ", \ and .
all show the right footer.

My concern is with to_regnamespace(). It parses the raw pattern as an
identifier, while the main query treats it as a pattern, and its behaviour
depends on the server version:

1. psql patterns may quote just part of a name (e.g. "FOO"bar matches
FOObar), but that isn't a valid identifier. On PG16+, to_regnamespace()
just returns NULL for it. On PG15 it throws "invalid name syntax" (see
REL_15_STABLE regproc.c, stringToQualifiedNameList()). So against a PG15
server, \dn "FOO"bar would fail entirely instead of listing the schema.
This matters even if the fix goes to master only, since the footer query
runs against any server version >= 150000. I haven't tried this against a
PG15 server; it's from reading the code.

2. On PG16+, to_regnamespace() goes through regnamespacein(), which also
accepts a numeric OID, so a numeric pattern resolves to the wrong schema:

CREATE SCHEMA "2200";
CREATE PUBLICATION e_pub_public FOR TABLES IN SCHEMA public;
\dn 2200
List of schemas
Name | Owner
------+-------
2200 | surya
Included in publications:
"e_pub_public"
That is the publication of public (OID 2200), not of schema "2200".

3. to_regnamespace() truncates to NAMEDATALEN-1 but the pattern match
doesn't, so an over-long pattern prints an empty list with a footer. With a
63-character schema e_long_xxx...x published by e_pub_long:

\dn e_long_xxx...xzzz
List of schemas
Name | Owner
------+-------
Included in publications:
"e_pub_long"
Contrived, but it's the same mismatch.

All three go away if the footer is keyed off the row the main query
actually returned, as I suggested earlier, rather than off the pattern:

if (pattern && PQntuples(res) == 1 && pset.sversion >= 150000)
{
...
"WHERE n.nspname = ");
appendStringLiteralConn(&buf, PQgetvalue(res, 0, 0), pset.db);
appendPQExpBufferStr(&buf, "\nORDER BY 1;");
That value is the real nspname, so the double-quote problem you described
doesn't come up. It doesn't depend on the server version, and the footer
always matches the displayed row. Like v8, it also stops master's habit of
showing a footer for a schema that wasn't listed. Today an unquoted \dn
E_Mixed prints an empty list with the publications of "E_Mixed". The one
new behaviour is that a wildcard pattern matching exactly one schema would
get a footer, which seems like the right result anyway.

Regarding tests, mixed case is what broke v4, and quoting/case folding is
exactly what the footer lookup has to get right, so a quoted mixed-case
name such as \dn "MySchema" with a publication would be worth adding, along
with a numeric name like the one above.

On backpatching, I'll leave that to the committer. It is a hard SQL error
for legitimate (unusual) schema names, and the fix is small.

Regards,
Surya Poondla

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Baji Shaik 2026-10-16 00:22:15 Re: [PATCH] Doc fix for autovacuum_max_parallel_workers
Previous Message Michael Paquier 2026-10-15 23:44:45 Re: Revert libpq servicefile connection option in v19 (info leak and uninterruptible backend DoS)