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-14 05:25:56
Message-ID: CAFj8pRDGBVxJNEqwS4gErJXtd5_wUrQLfZ_6rzWBDAnBdrSz_Q@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

út 14. 7. 2020 v 0:37 odesílatel David G. Johnston <
david(dot)g(dot)johnston(at)gmail(dot)com> napsal:

> On Mon, Jul 13, 2020 at 2:12 AM Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>
> wrote:
>
>> 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 case is a little bit more complex - domains are not subset of
>> relations. But relations (in Postgres) extends types.
>>
>
> Yeah, though in further working on this I dislike the saying "A composite
> type is a relation" (see Glossary and probably other spots). That a table
> auto-creates a separate composite type, and depends on it, manifests a
> certain link between the two but the type that represents the table is not
> a relation as it doesn't hold data, it is just a definition. If a
> composite type were a relation then whatever argument you use to justify
> that would seem to apply to non-composite types as well.
>
> I'm attaching version 2 as a plain diff (complete) instead of a patch.
>
> New with this version is the addition of tests for drop domain and drop
> type, and related documentation changes. Notably pointing out the fact
> that DROP TYPE drops all types, including domains.
>
> To recap, the interesting relation related behaviors these tests
> demonstrate are:
>
> A non-failure while performing a DROP "relation" IF EXISTS command means
> that a subsequent CREATE "relation" command will not fail due to the name
> already existing (other failures are of course possible).
>
> In the presence of multiple schemas a failure of a DROP "relation" IF
> EXISTS command does not necessarily mean that an corresponding CREATE
> "relation" command would fail - the found entry could belong to a non-first
> schema on the search_path while the creation will place the newly created
> object always on the first schema.
>
> The plain meaning of the opposite of "DROP IF EXISTS" (i.e., it's not an
> error if the specified object doesn't exist, just move on) is not what
> actually happens but rather we provide an additional test related to
> namespace occupation that is now documented.
>
> The latter two items are explicitly documented while the first is implicit
> and self-evident.
>

I think so now all changes are correct and valuable. I''l mark this patch
as ready for commit

Thank you for patch

Regards

Pavel

>
> David J.
>
>

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Dilip Kumar 2020-07-14 05:30:14 Re: replication_origin and replication_origin_lsn usage on subscriber
Previous Message David Rowley 2020-07-14 05:22:19 Re: Improvements in Copy From