Re: pg14 psql broke \d datname.nspname.relname
Mark Dilger <mark.dilger@enterprisedb.com>
From: Mark Dilger <mark.dilger@enterprisedb.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Robert Haas <robertmhaas@gmail.com>,
Peter Geoghegan <pg@bowt.ie>,
Justin Pryzby <pryzby@telsasoft.com>,
PostgreSQL Hackers <pgsql-hackers@postgresql.org>
Date: 2021-10-12T14:37:58Z
Lists: pgsql-hackers
> On Oct 12, 2021, at 7:30 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > > If the behavior v14 had implemented were "throw an error if the > first word doesn't match the current database name", perhaps nobody > would have questioned it. But that's not what we have. It's fairly > clear that neither you nor Mark thought very much about this case, > let alone tested it. Given that, I am not very pleased that you > are retroactively trying to justify breaking it by claiming that > it was already broken. It's been that way since 7.3 implemented > schemas, more or less, and nobody's complained about it. Therefore > I see little argument for changing that behavior. Changing it in > an already-released branch is especially suspect. I completely agree that we need to fix this. My question was only whether "fix" means to make it accept database.schema.table or whether it means to accept any.prefix.at.all.schema.table. It sounds like more people like the latter, so I'll go with that unless this debate rages on and a different conclusion is reached. — 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