> On Oct 11, 2021, at 3:37 PM, Tom Lane <t...@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. That could be "foo.bar"."baz", or
"foo"."bar"."baz", or "foo"."bar.baz", or even "public"."foo.bar.baz". The old
behavior seems a bit dangerous. There may be tables with all those names, and
the user may not have meant the one that we gave 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
