Horton

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

Mark Dilger <mark.dilger@enterprisedb.com>

View thread View on postgr.es
From: Mark Dilger <mark.dilger@enterprisedb.com>
To: Robert Haas <robertmhaas@gmail.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-26T17:04:15Z
Lists: pgsql-hackers

Attachments


> On Jan 17, 2022, at 1:54 PM, Robert Haas <robertmhaas@gmail.com> wrote:
> 
> + * dotcnt: how many separators were parsed from the pattern, by reference.
> + * Can be NULL.
> 
> But then:
> 
> +    Assert(dotcnt != NULL);

Removed the "Can be NULL" part, as that use case doesn't make sense.  The caller should always care whether the number of dots was greater than they are prepared to handle.

> 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.

Updated the header comments to include all parameters.

> It's also pretty clear that the behavior of patternToSQLRegex() is
> changing, but the function header comments are not.

Updated the header comments for this, too.

Also, rebased as necessary:

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.