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.