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

Поиск
Список
Период
Сортировка
От Mark Dilger
Тема Re: pg14 psql broke \d datname.nspname.relname
Дата
Msg-id 865799E0-3F75-47D6-9134-0967A731E9AF@enterprisedb.com
обсуждение исходный текст
Ответ на Re: pg14 psql broke \d datname.nspname.relname  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: pg14 psql broke \d datname.nspname.relname
Список pgsql-hackers

> On Apr 7, 2022, at 3:37 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>
>>
>> I don't know whether that's a bug fix for the existing code or some
>> new bit of functionality that \dconfig requires and nothing else
>> needs.
>
> Well, \dconfig needs it because it would like foo.bar to get processed
> as just a name.  But I think it's a bug fix because as things stood,
> if the caller doesn't provide a schemavar and the pattern contains a
> dot, the code just silently throws away the dot and all to the left.
> That doesn't seem very sane, even if it is a longstanding behavior.

The patch submitted changes processSQLNamePattern() to return a dot count by reference.  It's up to the caller to
decidewhether to raise an error.  If you pass in no schemavar, and you get back dotcnt=2, you know it parsed it as a
twopart pattern, and you can pg_fatal(...) or ereport(ERROR, ...) or whatever. 

It looks like I'll need to post a new version of the patch with an argument telling the function to ignore dots, but
I'mnot prepared to say that for sure.  

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






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

Предыдущее
От: Greg Stark
Дата:
Сообщение: Re: Add index scan progress to pg_stat_progress_vacuum
Следующее
От: Andres Freund
Дата:
Сообщение: Re: shared-memory based stats collector - v70