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

  1. Remove some recently-added pg_dump test cases.

  2. Allow db.schema.table patterns, but complain about random garbage.

  3. Improve error handling of HMAC computations

  4. Factor pattern-construction logic out of processSQLNamePattern.