Re: pg14 psql broke \d datname.nspname.relname
David G. Johnston <david.g.johnston@gmail.com>
From: "David G. Johnston" <david.g.johnston@gmail.com>
To: Mark Dilger <mark.dilger@enterprisedb.com>
Cc: Robert Haas <robertmhaas@gmail.com>, Julien Rouhaud <rjuju123@gmail.com>, PostgreSQL Hackers <pgsql-hackers@postgresql.org>,
Justin Pryzby <pryzby@telsasoft.com>, Stephen Frost <sfrost@snowman.net>, Peter Geoghegan <pg@bowt.ie>,
Tom Lane <tgl@sss.pgh.pa.us>
Date: 2022-03-15T20:03:48Z
Lists: 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.
Commits
-
Remove some recently-added pg_dump test cases.
- 75a006beef6c 14.3 landed
- a66e722cc118 15.0 landed
-
Allow db.schema.table patterns, but complain about random garbage.
- 4a66300acd8c 14.3 landed
- d2d35479796c 15.0 landed
-
Improve error handling of HMAC computations
- 5513dc6a304d 15.0 cited
-
Factor pattern-construction logic out of processSQLNamePattern.
- 2c8726c4b0a4 14.0 cited