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

Поиск
Список
Период
Сортировка
От Robert Haas
Тема Re: pg14 psql broke \d datname.nspname.relname
Дата
Msg-id CA+TgmoZdWUHNcEVgMVhcbWA8kJfNHLmiYwSH4S5aPoAqFaRoMQ@mail.gmail.com
обсуждение исходный текст
Ответ на Re: pg14 psql broke \d datname.nspname.relname  (Mark Dilger <mark.dilger@enterprisedb.com>)
Список pgsql-hackers
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



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Gilles Darold
Дата:
Сообщение: Re: [PATCH] Proposal for HIDDEN/INVISIBLE column
Следующее
От: Robert Haas
Дата:
Сообщение: Re: should we allow users with a predefined role to access pg_backend_memory_contexts view and pg_log_backend_memory_contexts function?