Re: pg14 psql broke \d datname.nspname.relname
Justin Pryzby <pryzby@telsasoft.com>
From: Justin Pryzby <pryzby@telsasoft.com>
To: Robert Haas <robertmhaas@gmail.com>
Cc: Stephen Frost <sfrost@snowman.net>, Tom Lane <tgl@sss.pgh.pa.us>, Peter Geoghegan <pg@bowt.ie>, Mark Dilger <mark.dilger@enterprisedb.com>, pgsql-hackers@postgresql.org
Date: 2021-10-13T16:54:26Z
Lists: pgsql-hackers
On Wed, Oct 13, 2021 at 12:46:27PM -0400, Robert Haas wrote: > On Tue, Oct 12, 2021 at 12:57 PM Justin Pryzby <pryzby@telsasoft.com> wrote: > > I would prefer if it errored if the datname didn't match the current database. > > After all, it would've helped me to avoid making a confusing problem report. > > How would you have felt if it had said something like: > > error: argument to \d should be of the form > [schema-name-pattern.]relation-name-pattern > > Would that have been better or worse for you than accepting a third > part of the pattern as a database name if and only if it matched the > current database name exactly? I don't normally type \d a.b.c. I think I copied it out of a log message and pasted it, and didn't even really know or expect it to work without removing the datname prefix. After it worked, I noticed a short while later when using the pg14 client that it had stopped working. It seems unfortunate if names from log messages qualified with datname were now rejected. Like this one: | automatic analyze of table "ts.child.cdrs_2021_10_12"... -- Justin
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