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

Поиск
Список
Период
Сортировка
От Mark Dilger
Тема Re: pg14 psql broke \d datname.nspname.relname
Дата
Msg-id E113768A-93CE-42F5-B654-CC12C2051AD9@enterprisedb.com
обсуждение исходный текст
Ответ на Re: pg14 psql broke \d datname.nspname.relname  (Robert Haas <robertmhaas@gmail.com>)
Ответы Re: pg14 psql broke \d datname.nspname.relname  (Robert Haas <robertmhaas@gmail.com>)
Re: pg14 psql broke \d datname.nspname.relname  (Andres Freund <andres@anarazel.de>)
Список 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




Вложения

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Andrew Dunstan
Дата:
Сообщение: Re: Non-decimal integer literals
Следующее
От: Robert Haas
Дата:
Сообщение: Re: refactoring basebackup.c