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

From Greg Stark
Subject Re: pg14 psql broke \d datname.nspname.relname
Date
Msg-id CAM-w4HNnB_A7JgP8O90r-1HrU6CBQoJmzG7tj74=opcatBPWew@mail.gmail.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  (Robert Haas <robertmhaas@gmail.com>)
List 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 by date:

Previous
From: Justin Pryzby
Date:
Subject: Re: pg14 psql broke \d datname.nspname.relname
Next
From: "David G. Johnston"
Date:
Subject: Re: shared-memory based stats collector - v70