Re: pg14 psql broke \d datname.nspname.relname
| От | David G. Johnston |
|---|---|
| Тема | Re: pg14 psql broke \d datname.nspname.relname |
| Дата | |
| Msg-id | CAKFQuwYA1J5spCwdWGevtSKoEexgburcPhgsBkq5nqcxvOOLZw@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: pg14 psql broke \d datname.nspname.relname (Mark Dilger <mark.dilger@enterprisedb.com>) |
| Список | pgsql-hackers |
On Tue, Mar 15, 2022 at 12:31 PM Mark Dilger <mark.dilger@enterprisedb.com> wrote:
> On Mar 15, 2022, at 12:27 PM, Robert Haas <robertmhaas@gmail.com> wrote:
>
> - Justin Pryzby, who originally discovered the problem, prefers the
> same behavior that I prefer long-term, but thinks Tom's behavior is
> better than doing nothing.
> - Mark Dilger, Isaac Moreland, Garick Hamlin, Alvaro Herrera, and
> Julien Rouhaud have commented on the thread but have not endorsed
> either of these dueling proposals.
I vote in favor of committing the patch, though I'd also say it's not super important to me.
I'm on board with leaving the v14 change in place - fixing the bug so that a matching database name is accepted (the whole copy-from-logs argument is quite compelling). I'm not too concerned about psql, since \d is mainly used interactively, and since the change will result in errors in pg_dump/pg_restore the usual due diligence for upgrading should handle the necessary tweaks should the case arise where bogus/ignore stuff is present.
David J.
В списке pgsql-hackers по дате отправления: