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