From: | Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> |
---|---|
To: | "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com> |
Cc: | PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: DROP relation IF EXISTS Docs and Tests - Bug Fix |
Date: | 2020-07-13 09:11:54 |
Message-ID: | CAFj8pRDgcuUQ6drjsncUKrDhxOofw+uRrmWTU6DSbGMMC2J=ow@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hi
čt 18. 6. 2020 v 0:47 odesílatel David G. Johnston <
david(dot)g(dot)johnston(at)gmail(dot)com> napsal:
> This is a follow-up to Bug # 16492 which also links to a thread sent to
> -hackers back in 2018.
>
> I'm firmly of the belief that the existing behavior of DROP relation IF
> EXISTS is flawed - it should not be an error if there is a namespace
> collision but the relkind of the existing relation doesn't match the
> relkind set by the DROP command.
>
> Since our documentation fails to elaborate on any additional behavior, and
> uses the relkind in the description, our users (few as they may be) are
> rightly calling this a bug. I loosely believe that any behavior change in
> this area should not be back-patched thus for released versions this is a
> documentation bug. I have attached a patch to fix that bug.
>
> In putting together the patch I noticed that the existing drop_if_exists
> regression tests exercise the DROP DOMAIN command. Out of curiosity I
> included that in my namespace testing and discovered that DROP DOMAIN
> thinks of itself as being a relation for purposes of IF EXISTS but DROP
> TABLE does not. I modified both DROP DOMAIN and the Glossary in response
> to this finding - though I suspect to find disagreement with my choice. I
> looked at pg_class for some guidance but a quick search for RELKIND_
> (DOMAIN) and finding nothing decided I didn't know enough and figured to
> punt on any further exploration of this inconsistency.
>
> The documentation and tests need to go in and be back-patched. After that
> happens I'll see whether and/or how to go about trying to get my PoV on the
> behavioral change committed.
>
I am reading this patch. I don't think so text for domains and types are
correct (or minimally it is little bit messy)
+ This parameter instructs <productname>PostgreSQL</productname> to
search
+ for the first instance of any relation with the provided name.
+ If no relations are found a notice is issued and the command ends.
+ If a relation is found then one of two things will happen:
+ if the relation is an domain it is dropped, otherwise the command
fails.
"If no relations are found ...".
This case is a little bit more complex - domains are not subset of
relations. But relations (in Postgres) extends types.
So in this case maybe modified text can be better
+ This parameter instructs <productname>PostgreSQL</productname> to
search
+ for the first instance of any domain with the provided name in
pg_type catalog.
+ If no type is found a notice is issued and the command ends.
+ If a type is found then one of two things will happen:
+ if the type is a domain it is dropped, otherwise the command fails.
Postgres knows
+ base types, composite types, relation related types and domain types.
Regards
Pavel
>
> David J.
>
>
From | Date | Subject | |
---|---|---|---|
Next Message | Pavel Stehule | 2020-07-13 09:26:26 | Re: DROP relation IF EXISTS Docs and Tests - Bug Fix |
Previous Message | Amit Kapila | 2020-07-13 09:09:16 | Re: Default setting for enable_hashagg_disk |