Re: pg14 psql broke \d datname.nspname.relname
От | Tom Lane |
---|---|
Тема | Re: pg14 psql broke \d datname.nspname.relname |
Дата | |
Msg-id | 529470.1633996189@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: pg14 psql broke \d datname.nspname.relname (Mark Dilger <mark.dilger@enterprisedb.com>) |
Ответы |
Re: pg14 psql broke \d datname.nspname.relname
|
Список | 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 по дате отправления: