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

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

In response to

Responses

Browse pgsql-hackers by date

  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