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: Alvaro Herrera <alvherre@alvh.no-ip.org>,
Robert Haas <robertmhaas@gmail.com>,
Justin Pryzby <pryzby@telsasoft.com>,
Stephen Frost <sfrost@snowman.net>,
Peter Geoghegan <pg@bowt.ie>,
PostgreSQL Hackers <pgsql-hackers@postgresql.org>
Date: 2021-11-05T14:58:15Z
Lists: pgsql-hackers
> On Nov 5, 2021, at 6:59 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > > Alvaro Herrera <alvherre@alvh.no-ip.org> writes: >> I think it would appropriate to normalize identifiers that are going to >> be stored in catalogs. As presented, this is a bit ridiculous and I see >> no reason to continue to support it. > > If we had any sort of convention about the encoding of identifiers stored > in shared catalogs, maybe we could do something about that. But we don't, > so any change is inevitably going to break someone's use-case. I only started the discussion about normalization to demonstrate that existing behavior does not require it. > In any case, that seems quite orthogonal to the question of how to treat > names with too many dots in them. Agreed. > Considering we are three days out from > freezing 14.1, I think it is time to stop the meandering discussion and > fix it. Agreed. > And by "fix", I mean revert to the pre-14 behavior. That's one solution. The patch I posted on October 20, and rebased two days ago, has not received any negative feedback. If you want to revert to pre-14 behavior for 14.1, do you oppose the patch going in for v15? (I'm not taking a position here, just asking what you'd prefer.) — 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