On Wed, Apr 6, 2022 at 12:07 PM Mark Dilger <mark.dil...@enterprisedb.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