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

Поиск
Список
Период
Сортировка
От Greg Stark
Тема Re: pg14 psql broke \d datname.nspname.relname
Дата
Msg-id CAM-w4HNnB_A7JgP8O90r-1HrU6CBQoJmzG7tj74=opcatBPWew@mail.gmail.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>)
Список pgsql-hackers
On Thu, 7 Apr 2022 at 22:32, Robert Haas <robertmhaas@gmail.com> wrote:
>
> On Thu, Apr 7, 2022 at 7:41 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
>
> > Possibly a better idea is to add an enum argument telling the function
> > what to do (parse the whole thing as one name regardless of dots,
> > parse as two names if there's a dot, throw error if there's a dot,
> > etc etc as needed by existing call sites).  Perhaps some of the
> > existing arguments could be merged into such an enum, too.
>
> AFAICS there's not much to be done about the fact
> that one caller wants pg_log_error + exit(2), another wants fatal(), a
> third PQfinish(conn) and exit_nicely(), and the last termPQExpBuffer()
> and return false.

That doesn't seem to be entirely inconsistent with what Tom describes.
Instead of "throw an error" the function would return an error and
possibly some extra info which the caller would use to handle the
error appropriately.

It still has the nice property that the decision that it is in fact an
error would be made inside the parsing function based on the enum
declaring what's intended. And it wouldn't return a possibly bogus
parsing with information the caller might use to infer it isn't what
was desired (or fail to).

-- 
greg



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

Предыдущее
От: Justin Pryzby
Дата:
Сообщение: Re: pg14 psql broke \d datname.nspname.relname
Следующее
От: "David G. Johnston"
Дата:
Сообщение: Re: shared-memory based stats collector - v70