Re: pg14 psql broke \d datname.nspname.relname

On Wed, Oct 13, 2021 at 4:43 PM Mark Dilger
<mark.dilger@enterprisedb.com> wrote:
> The function where the processing occurs is processSQLNamePattern, which is called by pg_dump, pg_dumpall, and psql.
Allthree callers expect processSQLNamePattern to append where-clauses to a buffer, not to execute any sql of its own.
Ipropose that processSQLNamePattern return an error code if the pattern contains more than three parts, but otherwise
insertthe database portion into the buffer as a "pg_catalog.current_database() OPERATOR(pg_catalog.=) <database>",
where<database> is a properly escaped representation of the database portion.  Maybe someday we can change that to
OPERATOR(pg_catalog.~),but for now we lack the sufficient logic for handling multiple matching database names.  (The
situationis different for pg_dumpall, as it's using the normal logic for matching a relation name, not for matching a
database,and we'd still be fine matching that against a pattern.) 

I agree with matching using OPERATOR(pg_catalog.=) but I think it
should be an error, not a silently-return-nothing case.

> In pg_dumpall, --exclude-database=more.than.one.part would give an error about too many dotted parts rather than
simplytrying to exclude the last "part" and silently ignoring the prefix, which I think is what v13's pg_dumpall would
do. --exclude-database=db?? would work to exclude four character database names beginning in "db". 

Those things sound good.

--
Robert Haas
EDB: http://www.enterprisedb.com