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

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.

David J.