Re: pg14 psql broke \d datname.nspname.relname
Greg Stark <stark@mit.edu>
From: Greg Stark <stark@mit.edu>
To: Robert Haas <robertmhaas@gmail.com>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, Mark Dilger <mark.dilger@enterprisedb.com>, Andres Freund <andres@anarazel.de>, Julien Rouhaud <rjuju123@gmail.com>, PostgreSQL Hackers <pgsql-hackers@postgresql.org>,
Justin Pryzby <pryzby@telsasoft.com>, Stephen Frost <sfrost@snowman.net>, Peter Geoghegan <pg@bowt.ie>
Date: 2022-04-08T03:39:47Z
Lists: 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
Commits
-
Remove some recently-added pg_dump test cases.
- 75a006beef6c 14.3 landed
- a66e722cc118 15.0 landed
-
Allow db.schema.table patterns, but complain about random garbage.
- 4a66300acd8c 14.3 landed
- d2d35479796c 15.0 landed
-
Improve error handling of HMAC computations
- 5513dc6a304d 15.0 cited
-
Factor pattern-construction logic out of processSQLNamePattern.
- 2c8726c4b0a4 14.0 cited