Re: DROP relation IF EXISTS Docs and Tests - Bug Fix - Mailing list pgsql-hackers
| From | Pavel Stehule |
|---|---|
| Subject | Re: DROP relation IF EXISTS Docs and Tests - Bug Fix |
| Date | |
| Msg-id | CAFj8pRDgcuUQ6drjsncUKrDhxOofw+uRrmWTU6DSbGMMC2J=ow@mail.gmail.com Whole thread Raw |
| In response to | DROP relation IF EXISTS Docs and Tests - Bug Fix ("David G. Johnston" <david.g.johnston@gmail.com>) |
| Responses |
Re: DROP relation IF EXISTS Docs and Tests - Bug Fix
Re: DROP relation IF EXISTS Docs and Tests - Bug Fix |
| List | pgsql-hackers |
Hi
čt 18. 6. 2020 v 0:47 odesílatel David G. Johnston <david.g.johnston@gmail.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.
+ 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
+ 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.
pgsql-hackers by date: