Re: DROP relation IF EXISTS Docs and Tests - Bug Fix

Поиск
Список
Период
Сортировка
От Pavel Stehule
Тема Re: DROP relation IF EXISTS Docs and Tests - Bug Fix
Дата
Msg-id CAFj8pRACtwERV0bHNVxQZnbDY3SwO7WovLQL8xhgUFZWNVWq-A@mail.gmail.com
обсуждение исходный текст
Ответ на Re: DROP relation IF EXISTS Docs and Tests - Bug Fix  (Pavel Stehule <pavel.stehule@gmail.com>)
Список pgsql-hackers


po 13. 7. 2020 v 11:11 odesílatel Pavel Stehule <pavel.stehule@gmail.com> napsal:
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.

"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.

create type footyp as (a int, b int);
postgres=# drop domain if exists footyp;
ERROR:  "footyp" is not a domain
postgres=#


Regards

Pavel



 

David J.

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Pavel Stehule
Дата:
Сообщение: Re: DROP relation IF EXISTS Docs and Tests - Bug Fix
Следующее
От: Amit Kapila
Дата:
Сообщение: Re: PATCH: logical_work_mem and logical streaming of large in-progress transactions