On Fri, Oct 16, 2026 at 11:17 AM surya poondla <[email protected]> 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
v9-0001-Fix-escapes-for-psql-describe-schema-patterns.patch
Description: Binary data
