Re: pg14 psql broke \d datname.nspname.relname - Mailing list pgsql-hackers

From David G. Johnston
Subject Re: pg14 psql broke \d datname.nspname.relname
Date
Msg-id CAKFQuwYA1J5spCwdWGevtSKoEexgburcPhgsBkq5nqcxvOOLZw@mail.gmail.com
Whole thread Raw
In response to Re: pg14 psql broke \d datname.nspname.relname  (Mark Dilger <mark.dilger@enterprisedb.com>)
List 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 by date:

Previous
From: Justin Pryzby
Date:
Subject: Re: pg14 psql broke \d datname.nspname.relname
Next
From: Nathan Bossart
Date:
Subject: Re: add checkpoint stats of snapshot and mapping files of pg_logical dir