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

Tom Lane <tgl@sss.pgh.pa.us>

From: Tom Lane <tgl@sss.pgh.pa.us>
To: Robert Haas <robertmhaas@gmail.com>
Cc: 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-07T22:37:11Z
Lists: pgsql-hackers
Robert Haas <robertmhaas@gmail.com> writes:
> I still have a vague feeling that there's probably some way of doing
> this better, but had more or less resolved to commit this patch as is
> anyway and had that all queued up. But then I had to go to a meeting
> and when I came out I discovered that Tom had done this:

Sorry, it didn't occur to me that that would impinge on what you
were doing over here ... though in retrospect I should have thought
of it.

> 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.

			regards, tom lane



Commits

  1. Remove some recently-added pg_dump test cases.

  2. Allow db.schema.table patterns, but complain about random garbage.

  3. Improve error handling of HMAC computations

  4. Factor pattern-construction logic out of processSQLNamePattern.