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 по дате отправления: