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

On Tue, Oct 12, 2021 at 5:21 PM Mark Dilger
<mark.dilger@enterprisedb.com> wrote:
> I wasn't thinking critically enough about how psql handles \d when I accepted Justin's initial characterization of the bug.  The psql client has never thought about the stuff to the left of the schema name as a database name, even if some users thought about it that way.  It also doesn't think about the pattern as a literal string.

I agree.

> The psql client's interpretation of the pattern is a bit of a chimera, following shell glob patterns for some things and POSIX regex rules for others.

Yes. And that's pretty weird, but it's long-established precedent so
we have to deal with it.

> Splitting the pattern on all the dots and throwing away any additional leftmost fields is a bug, ...

I also agree with you right up to here.

> and when you stop doing that, passing additional dots through to the POSIX regular expression for processing is the most natural thing to do.  This is, in fact, how v14 works.  It is a bit debatable whether treating the first dot as a separator and the additional dots as stuff to be passed through is the right thing, so we could call the v14 behavior a mis-feature, but it's not as clearcut as the discussion upthread suggested.  Reverting to v13 behavior seems wrong, but I'm now uncertain how to proceed.

But not this part, or at least not entirely.

If we pass the dots through to the POSIX regular expression, we can
only do that either for the table name or the schema name, not both -
either the first or last dot must mark the boundary between the two.
That means that you can't use all the same regexy things for one as
you can for the other, which is a strange system. I knew that your
patch made it do that, and I committed it that way because I didn't
think it really mattered, and also because the whole system is already
pretty strange, so what's one more bit of strangeness?

I think there are at least 3 defensible behaviors here:

1. Leave it like it is. If there is more than one dot, the extra ones
are part of one of the regex-glob thingies.

2. If there is more than one dot, error! Tell the user they messed up.

3. If there are exactly two dots, treat it as db-schema-user. Accept
it if the dbname matches the current db, and otherwise say we can't
access the named db. If there are more than two dots, then (a) it's an
error as in (2) or (b) the extra ones become part of the regex-glob
thingies as in (2).

The thing that's unprincipled about (3) is that we can't support a
regexp-glob thingy there -- we can only test for a literal string
match. And I already said what I thought was wrong with (1). But none
of these are horrible, and I don't think it really matters which one
we adopt. I don't even know if I can really rank the choices I just
listed against each other. Before I was arguing for (3a) but I'm not
sure I actually like that one particularly better.

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