Re: pg14 psql broke \d datname.nspname.relname
Tom Lane <tgl@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Justin Pryzby <pryzby@telsasoft.com>
Cc: Robert Haas <robertmhaas@gmail.com>,
Mark Dilger <mark.dilger@enterprisedb.com>,
Greg Stark <stark@mit.edu>,
Andres Freund <andres@anarazel.de>,
Julien Rouhaud <rjuju123@gmail.com>, pgsql-hackers@postgresql.org,
Stephen Frost <sfrost@snowman.net>, Peter Geoghegan <pg@bowt.ie>
Date: 2022-04-19T15:26:45Z
Lists: pgsql-hackers
Justin Pryzby <pryzby@telsasoft.com> writes: > On Tue, Apr 19, 2022 at 10:00:01AM -0400, Robert Haas wrote: >> (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? > I thought the plan was to backpatch to v14. > v14 psql had an unintentional behavior change, rejecting \d > datname.nspname.relname. I agree that the v14 behavior is a bug, so ordinarily I'd vote for back-patching. A possible objection to doing that is that the patch changes the APIs of processSQLNamePattern and patternToSQLRegex. We would avoid making such a change in core-backend APIs in a minor release, but I'm not certain whether there are equivalent stability concerns for src/fe_utils/. On the whole I'd vote for (B), with (C) as second choice. regards, tom lane
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