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

On Fri, Oct 16, 2026 at 11:17 AM surya poondla <suryapoondla4(at)gmail(dot)com> wrote:
>
>

Thanks for giving feedback on this patch. PSA v9.

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

DONE - Rebased to the latest master.

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

DONE - Fixed as suggested.

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

DONE - Added some tests for mixed-case and numeric-only schema names.

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

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