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

po 13. 7. 2020 v 11:11 odesílatel Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>
napsal:

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

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