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

From: Greg Stark <stark(at)mit(dot)edu>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Mark Dilger <mark(dot)dilger(at)enterprisedb(dot)com>, Andres Freund <andres(at)anarazel(dot)de>, Julien Rouhaud <rjuju123(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>, Justin Pryzby <pryzby(at)telsasoft(dot)com>, Stephen Frost <sfrost(at)snowman(dot)net>, Peter Geoghegan <pg(at)bowt(dot)ie>
Subject: Re: pg14 psql broke \d datname.nspname.relname
Date: 2022-04-08 03:39:47
Message-ID: CAM-w4HNnB_A7JgP8O90r-1HrU6CBQoJmzG7tj74=opcatBPWew@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, 7 Apr 2022 at 22:32, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
>
> On Thu, Apr 7, 2022 at 7:41 PM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message David G. Johnston 2022-04-08 03:51:10 Re: shared-memory based stats collector - v70
Previous Message Justin Pryzby 2022-04-08 03:04:44 Re: pg14 psql broke \d datname.nspname.relname