Re: pg14 psql broke \d datname.nspname.relname
Robert Haas <robertmhaas@gmail.com>
From: Robert Haas <robertmhaas@gmail.com>
To: Mark Dilger <mark.dilger@enterprisedb.com>
Cc: Julien Rouhaud <rjuju123@gmail.com>,
PostgreSQL Hackers <pgsql-hackers@postgresql.org>, Justin Pryzby <pryzby@telsasoft.com>, Stephen Frost <sfrost@snowman.net>,
Peter Geoghegan <pg@bowt.ie>, Tom Lane <tgl@sss.pgh.pa.us>
Date: 2022-01-17T21:54:12Z
Lists: pgsql-hackers
On Mon, Jan 17, 2022 at 1:06 PM Mark Dilger <mark.dilger@enterprisedb.com> wrote: > > On Jan 15, 2022, at 12:28 AM, Julien Rouhaud <rjuju123@gmail.com> wrote: > > Could you send a rebased version? > Yes. Here it is: This is not a full review, but I just noticed that: + * dotcnt: how many separators were parsed from the pattern, by reference. + * Can be NULL. But then: + Assert(dotcnt != NULL); On a related note, it's unclear why you've added three new arguments to processSQLNamePattern() but only one of them gets a mention in the function header comment. It's also pretty clear that the behavior of patternToSQLRegex() is changing, but the function header comments are not. -- Robert Haas EDB: http://www.enterprisedb.com
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