Re: pg14 psql broke \d datname.nspname.relname

Mark Dilger <mark.dilger@enterprisedb.com>

From: Mark Dilger <mark.dilger@enterprisedb.com>

To: Justin Pryzby <pryzby@telsasoft.com>

Cc: Robert Haas <robertmhaas@gmail.com>, pgsql-hackers@postgresql.org

Date: 2021-10-11T22:32:16Z

Lists: pgsql-hackers

> On Oct 11, 2021, at 3:26 PM, Justin Pryzby <pryzby@telsasoft.com> wrote:
> 
> It looks like before v13 any "datname" prefix was ignored.

The evidence so far suggests that something is broken in v14, but it is less clear to me what the appropriate behavior is.  The v14 psql is rejecting even a correctly named database.schema.table, but v13 psql accepted lots.of.nonsense.schema.table, and neither of those seems at first glance to be correct.  But perhaps there are good reasons for ignoring the nonsense prefixes?

—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

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