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

On Wed, Apr 6, 2022 at 12:07 PM Mark Dilger
<mark(dot)dilger(at)enterprisedb(dot)com> wrote:
> I was able to clean up the "if (left && want_literal_dbname)" stuff, though.

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:

--- a/src/fe_utils/string_utils.c
+++ b/src/fe_utils/string_utils.c
@@ -918,8 +918,12 @@ processSQLNamePattern(PGconn *conn, PQExpBuffer
buf, const char *pattern,
* Convert shell-style 'pattern' into the regular expression(s) we want to
* execute. Quoting/escaping into SQL literal format will be done below
* using appendStringLiteralConn().
+ *
+ * If the caller provided a schemavar, we want to split the pattern on
+ * ".", otherwise not.
*/
- patternToSQLRegex(PQclientEncoding(conn), NULL, &schemabuf, &namebuf,
+ patternToSQLRegex(PQclientEncoding(conn), NULL,
+ (schemavar ? &schemabuf : NULL), &namebuf,
pattern, force_escape);

/*

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. A related point that I had noticed during review is that these
existing tests look pretty bogus:

if (namebuf.len > 2)

if (schemabuf.len > 2)

In the v13 code, these tests occur at a point where we've definitely
added ^( to the buffer, but possibly nothing else. But starting in v14
that's no longer the case. So probably this test should be changed
somehow. The proposed patch changes these to something like this:

+ if (schemavar && schemabuf.len > 2)

But that doesn't really seem like it's fixing the problem I'm talking about.

--
Robert Haas
EDB: http://www.enterprisedb.com