Re: pg14 psql broke \d datname.nspname.relname - Mailing list pgsql-hackers

From Tom Lane
Subject Re: pg14 psql broke \d datname.nspname.relname
Date
Msg-id 529470.1633996189@sss.pgh.pa.us
Whole thread Raw
In response to Re: pg14 psql broke \d datname.nspname.relname  (Mark Dilger <mark.dilger@enterprisedb.com>)
Responses Re: pg14 psql broke \d datname.nspname.relname
List pgsql-hackers
Mark Dilger <mark.dilger@enterprisedb.com> writes:
> But since we allow tables and schemas with dotted names in them, I'm uncertain what  \d foo.bar.baz is really asking.
That could 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. 

You are attacking a straw man here.  To use a period in an identifier,
you have to double-quote it; that's the same in SQL or \d.

regression=# create table "foo.bar" (f1 int);
CREATE TABLE
regression=# \d foo.bar
Did not find any relation named "foo.bar".
regression=# \d "foo.bar"
              Table "public.foo.bar"
 Column |  Type   | Collation | Nullable | Default
--------+---------+-----------+----------+---------
 f1     | integer |           |          |

According to a quick test, you did not manage to break that in v14.

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

I do not understand why you're even questioning that.  The old
behavior had stood for a decade or two without complaints.

            regards, tom lane



pgsql-hackers by date:

Previous
From: Isaac Morland
Date:
Subject: Re: pg14 psql broke \d datname.nspname.relname
Next
From: Fujii Masao
Date:
Subject: Re: Accommodate startup process in a separate ProcState array slot instead of in MaxBackends slots.