Re: pg14 psql broke \d datname.nspname.relname
Robert Haas <robertmhaas@gmail.com>
From: Robert Haas <robertmhaas@gmail.com>
To: Mark Dilger <mark.dilger@enterprisedb.com>
Cc: Greg Stark <stark@mit.edu>, Tom Lane <tgl@sss.pgh.pa.us>,
Andres Freund <andres@anarazel.de>, 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>
Date: 2022-04-19T14:00:01Z
Lists: pgsql-hackers
On Mon, Apr 18, 2022 at 3:39 PM Mark Dilger <mark.dilger@enterprisedb.com> wrote: > Since there hasn't been any agreement on that point, I've just rebased the patch to apply cleanly against the current master: This looks OK to me. There may be better ways to do some of it, but there's no rule against further improving the code later. Also, since the issue was introduced in v14, we probably shouldn't wait forever to do something about it. However, there is a procedural issue here now that we are past feature freeze. I think someone could defensibly take any of the following positions: (A) This is a new feature. Wait for v16. (B) This is a bug fix. Commit it now and back-patch to v14. (C) This is a cleanup that is OK to put into v15 even after feature freeze but since it is a behavior change we shouldn't back-patch it. I vote for (C). What do other people think? -- Robert Haas EDB: http://www.enterprisedb.com
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