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

> On Oct 11, 2021, at 3:37 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>
>> REL_13_STABLE appears to accept any amount of nonsense you like:
>
> Yeah, I'm pretty sure that the old rule was to just ignore whatever
> appeared in the database-name position.  While we could tighten that
> up to insist that it match the current DB's name, I'm not sure that
> I see the point.  There's no near-term prospect of doing anything
> useful with some other DB's name there, so being more restrictive
> seems like it'll probably break peoples' scripts to little purpose.

You appear correct about the old behavior.  It's unclear how intentional it was.  There was a schema buffer and a name
buffer,and while parsing the name, if a dot was encountered, the contents just parsed were copied into the schema
buffer. If multiple dots were encountered, that had the consequence of blowing away the earlier ones. 

But since we allow tables and schemas with dotted names in them, I'm uncertain what  \d foo.bar.baz is really asking.
Thatcould be "foo.bar"."baz", or "foo"."bar"."baz", or "foo"."bar.baz", or even "public"."foo.bar.baz".  The old
behaviorseems a bit dangerous.  There may be tables with all those names, and the user may not have meant the one that
wegave them. 

The v14 code is no better.  It just assumes that is "foo"."bar.baz".  So (with debugging statements included):

foo=# create table "foo.bar.baz" (i integer);
CREATE TABLE
foo=# \d public.foo.bar.baz
Converting "public.foo.bar.baz"
GOT "^(public)$" . "^(foo.bar.baz)$"
            Table "public.foo.bar.baz"
 Column |  Type   | Collation | Nullable | Default
--------+---------+-----------+----------+---------
 i      | integer |           |          |

I expect I'll have to submit a patch restoring the old behavior, but I wonder if that's the best direction to go.

—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company