Re: pg14 psql broke \d datname.nspname.relname - Mailing list pgsql-hackers

From Mark Dilger
Subject Re: pg14 psql broke \d datname.nspname.relname
Date
Msg-id E113768A-93CE-42F5-B654-CC12C2051AD9@enterprisedb.com
Whole thread Raw
In response to Re: pg14 psql broke \d datname.nspname.relname  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: pg14 psql broke \d datname.nspname.relname
Re: pg14 psql broke \d datname.nspname.relname
List pgsql-hackers

> 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
ofdots 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:



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




Attachment

pgsql-hackers by date:

Previous
From: Andrew Dunstan
Date:
Subject: Re: Non-decimal integer literals
Next
From: Robert Haas
Date:
Subject: Re: refactoring basebackup.c