DROP relation IF EXISTS Docs and Tests - Bug Fix

"David G. Johnston" <david.g.johnston@gmail.com> writes:

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.

I don't particularly agree, as I said in the other thread. The core
point here is that it's not clear to me why the specific error of
"wrong relkind" deserves a pass, while other errors such as "you're
not the owner" don't. Both of those cases suggest that you're not
targeting the relation you think you are, and both of them would get
in the way of a subsequent CREATE. To me, success of DROP IF EXISTS
should mean "the coast is clear to do a CREATE". With an exception
like this, a success would mean nothing at all.

Another point here is that we have largely the same issue with respect
to different subclasses of routines (functions/procedures/aggregates)
and types (base types/composite types/domains). If we do change
something then I'd want to see it done consistently across all these
cases.

regards, tom lane

On Wed, Jun 17, 2020 at 4:32 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:

"David G. Johnston" <david.g.johnston@gmail.com> writes:

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.

The other thread:

/messages/by-id/CAKFQuwY90=GSX_65cYdAm18TWCv4CvnPdHCuH92qfzKSYaFnxQ@mail.gmail.com

I don't particularly agree, as I said in the other thread. The core

point here is that it's not clear to me why the specific error of
"wrong relkind" deserves a pass, while other errors such as "you're
not the owner" don't.

Because if you're not the owner then by definition the expected target
exists and a drop is attempted - which can still fail.

Both of those cases suggest that you're not

targeting the relation you think you are, and both of them would get
in the way of a subsequent CREATE.

Agreed, as noted on the other thread we actually are not sufficiently
paranoid in this situation. Specifically, we allow dropping a relation
based upon a search_path search when the target it not on the first entry
in the search_path. I'd be glad to see that hole closed up - but this is
still broken even when the name is always schema qualified.

To me, success of DROP IF EXISTS

should mean "the coast is clear to do a CREATE". With an exception
like this, a success would mean nothing at all.

To me and at least some users DROP IF EXISTS means that the specific object
I specified no longer exists, period.

If you want access to the behavior you describe go and write DROP ROUTINE.
As noted on the other thread I think that is a bad option but hey, it does
have the benefit of doing exactly what you describe.

Users can write multiple the drop commands necessary to get their create
command to execute successfully. If the create command fails they can
react to that and figure out where their misunderstanding was. Is that
really so terrible?

Another point here is that we have largely the same issue with respect

to different subclasses of routines (functions/procedures/aggregates)
and types (base types/composite types/domains). If we do change
something then I'd want to see it done consistently across all these
cases.

Ok. I don't necessarily disagree. In fact the patch I submitted, which is
the on-topic discussion for this thread, brings up the very point that
domain behavior here is presently inconsistent.

At least for DROP TABLE IF EXISTS if we close up the hole with search_path
resolution by introducing an actual "found relation in the wrong location"
error then the risk will have been removed - which exists outside of the IF
EXISTS logic - and instead of not dropping a table and throwing an error we
just are not dropping a table.

So, in summary, this thread is to document the current behavior [actual doc
bug fix]. There is probably another thread buried in all of this for going
through and finding other undocumented behaviors for other object types
[potential doc bug fixes]. Then a thread for solidifying search_path
handling to actually fill in missing seemingly desirable safety features to
avoid drop target mis-identification (so we don't actually drop the wrong
object) [feature]. Then a thread to discuss whether or not dropping an
object that wasn't of the relkind that user specified should be an error
[bug fix held up due to insufficient safety features]. Then a thread to
discuss DROP ROUTINE [user choice of convenience over safety].

David J.

Hi

čt 18. 6. 2020 v 0:47 odesílatel David G. Johnston <
david.g.johnston@gmail.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.

Regards

Pavel

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

Hi

čt 18. 6. 2020 v 0:47 odesílatel David G. Johnston <
david.g.johnston@gmail.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=#

On Mon, Jul 13, 2020 at 2:12 AM Pavel Stehule <pavel.stehule@gmail.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.

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

On Mon, Jul 13, 2020 at 2:12 AM Pavel Stehule <pavel.stehule@gmail.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

On Tue, Jul 14, 2020 at 07:25:56AM +0200, Pavel Stehule wrote:

�t 14. 7. 2020 v 0:37 odes�latel David G. Johnston <david.g.johnston@gmail.com> napsal:

On Mon, Jul 13, 2020 at 2:12 AM Pavel Stehule <pavel.stehule@gmail.com> wrote:

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

This is failing relevant tests in cfbot:

drop_if_exists ... FAILED 450 ms

--
Justin

On Tue, Jul 14, 2020 at 5:40 AM Justin Pryzby <pryzby@telsasoft.com> wrote:

On Tue, Jul 14, 2020 at 07:25:56AM +0200, Pavel Stehule wrote:

út 14. 7. 2020 v 0:37 odesílatel David G. Johnston <

david.g.johnston@gmail.com> napsal:

On Mon, Jul 13, 2020 at 2:12 AM Pavel Stehule <pavel.stehule@gmail.com>

wrote:

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

This is failing relevant tests in cfbot:

drop_if_exists ... FAILED 450 ms

Oops, did a minor whitespace cleanup in the test file and didn't re-copy
expected output. I'm actually going to try and clean up the commenting in
the test file a bit to make it easier to read, and split out the glossary
changes into their own diff so that the bulk of the changes can be
back-patched.

Further comments welcome so I'm putting it back into needs review for the
moment while I work on the refactor.

David J.

út 14. 7. 2020 v 15:55 odesílatel David G. Johnston <
david.g.johnston@gmail.com> napsal:

On Tue, Jul 14, 2020 at 5:40 AM Justin Pryzby <pryzby@telsasoft.com>
wrote:

On Tue, Jul 14, 2020 at 07:25:56AM +0200, Pavel Stehule wrote:

út 14. 7. 2020 v 0:37 odesílatel David G. Johnston <

david.g.johnston@gmail.com> napsal:

On Mon, Jul 13, 2020 at 2:12 AM Pavel Stehule <

pavel.stehule@gmail.com> wrote:

I think so now all changes are correct and valuable. I''l mark this

patch

as ready for commit

This is failing relevant tests in cfbot:

drop_if_exists ... FAILED 450 ms

Oops, did a minor whitespace cleanup in the test file and didn't re-copy
expected output. I'm actually going to try and clean up the commenting in
the test file a bit to make it easier to read, and split out the glossary
changes into their own diff so that the bulk of the changes can be
back-patched.

Further comments welcome so I'm putting it back into needs review for the
moment while I work on the refactor.

attached fixed patch

all tests passed
doc build without problems

On Tue, Jul 14, 2020 at 6:56 AM Pavel Stehule <pavel.stehule@gmail.com>
wrote:

út 14. 7. 2020 v 15:55 odesílatel David G. Johnston <
david.g.johnston@gmail.com> napsal:

Further comments welcome so I'm putting it back into needs review for the
moment while I work on the refactor.

attached fixed patch

all tests passed
doc build without problems

Thanks.

Actually, one question I didn't pose before, does the SQL standard define
DROP TYPE to target domains while also providing for a DROP DOMAIN
command? Do drop commands for the other types we have not exist because
those aren't SQL standard types (or the standard they are standard types
but the commands aren't defined)?

David J.

út 14. 7. 2020 v 16:09 odesílatel David G. Johnston <
david.g.johnston@gmail.com> napsal:

On Tue, Jul 14, 2020 at 6:56 AM Pavel Stehule <pavel.stehule@gmail.com>
wrote:

út 14. 7. 2020 v 15:55 odesílatel David G. Johnston <
david.g.johnston@gmail.com> napsal:

Further comments welcome so I'm putting it back into needs review for
the moment while I work on the refactor.

attached fixed patch

all tests passed
doc build without problems

Thanks.

Actually, one question I didn't pose before, does the SQL standard define
DROP TYPE to target domains while also providing for a DROP DOMAIN
command? Do drop commands for the other types we have not exist because
those aren't SQL standard types (or the standard they are standard types
but the commands aren't defined)?

It looks like Postgres user defined types are something else than ANSI SQL
- so CREATE TYPE and DROP TYPE did different work.

In the section DROP TYPE in ANSI SQL there is not mentioned any relation to
domains.

On Tue, Jul 14, 2020 at 7:21 AM Pavel Stehule <pavel.stehule@gmail.com>
wrote:

út 14. 7. 2020 v 16:09 odesílatel David G. Johnston <
david.g.johnston@gmail.com> napsal:

On Tue, Jul 14, 2020 at 6:56 AM Pavel Stehule <pavel.stehule@gmail.com>
wrote:

út 14. 7. 2020 v 15:55 odesílatel David G. Johnston <
david.g.johnston@gmail.com> napsal:

Further comments welcome so I'm putting it back into needs review for
the moment while I work on the refactor.

attached fixed patch

all tests passed
doc build without problems

Thanks.

Actually, one question I didn't pose before, does the SQL standard define
DROP TYPE to target domains while also providing for a DROP DOMAIN
command? Do drop commands for the other types we have not exist because
those aren't SQL standard types (or the standard they are standard types
but the commands aren't defined)?

It looks like Postgres user defined types are something else than ANSI SQL
- so CREATE TYPE and DROP TYPE did different work.

In the section DROP TYPE in ANSI SQL there is not mentioned any relation
to domains.

Attaching a backpatch-able patch for the main docs and tests, v4
Added a head-only patch for the glossary changes, set to v4 as well.

I didn't try and address any SQL standard dynamics here.

David J.

Hi!

I've skimmed through the thread and checked the patchset. Everything
looks good, except one paragraph, which doesn't look completely clear.

+  <para>
+   This emulates the functionality provided by
+   <xref linkend="sql-createtype"/> but sets the created object's
+   <glossterm linkend="glossary-type-definition">type definition</glossterm>
+   to domain.
+  </para>

As I get it states that CREATE DOMAIN somehow "emulates" CREATE TYPE.
Could you please, rephrase it? It looks confusing to me yet.

------
Regards,
Alexander Korotkov

On Tue, Sep 15, 2020 at 3:48 PM Alexander Korotkov <aekorotkov@gmail.com>
wrote:

Hi!

I've skimmed through the thread and checked the patchset. Everything
looks good, except one paragraph, which doesn't look completely clear.

+  <para>
+   This emulates the functionality provided by
+   <xref linkend="sql-createtype"/> but sets the created object's
+   <glossterm linkend="glossary-type-definition">type
definition</glossterm>
+   to domain.
+  </para>

As I get it states that CREATE DOMAIN somehow "emulates" CREATE TYPE.
Could you please, rephrase it? It looks confusing to me yet.

I'll look at it.

My main point here is that writing "CREATE TYPE typename AS DOMAIN" would
be expected, with the appropriate sub-specification, similar to "CREATE
TYPE typename AS RANGE". While the syntax wasn't rolled up into "CREATE
TYPE" proper "CREATE DOMAIN" effectively does the same thing - creates a
type of domain (just ask CREATE TYPE AS RANGE creates a type of range).
I'm calling "a type of something" the type's "type domain". CREATE DOMAIN
emulates the non-existent "CREATE TYPE typename AS DOMAIN" command.

David J.

"David G. Johnston" <david.g.johnston@gmail.com> writes:

My main point here is that writing "CREATE TYPE typename AS DOMAIN" would
be expected, with the appropriate sub-specification, similar to "CREATE
TYPE typename AS RANGE".

Well, that point seems entirely invented. CREATE DOMAIN is in the
SQL standard:

<domain definition> ::=
CREATE DOMAIN <domain name> [ AS ] <predefined type>
[ <default clause> ]
[ <domain constraint>... ]
[ <collate clause> ]

While SQL does also have a CREATE TYPE command, domains are not
among the kinds of type it can make. So that separation is
very much per spec.

I don't personally find the doc changes proposed here to be a good idea.
001 seems to add a lot of verbosity and not much else. 002 invents terms
used nowhere else in our docs, which seems more confusing than anything
else. It is very badly in need of copy-editing, as well.

Also, I think the phrase you are looking for might be "type category".
Using "type definition" to mean that seems completely wrong. Deciding
that capitalized Type means something special is something I might expect
to find in one of the more abstruse philosophers, but it's not a great
idea in the Postgres manual ... especially when you then use different
terminology elsewhere.

regards, tom lane

On Wed, Sep 16, 2020 at 4:42 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:

"David G. Johnston" <david.g.johnston@gmail.com> writes:

My main point here is that writing "CREATE TYPE typename AS DOMAIN" would
be expected, with the appropriate sub-specification, similar to "CREATE
TYPE typename AS RANGE".

Well, that point seems entirely invented. CREATE DOMAIN is in the
SQL standard:

<domain definition> ::=
CREATE DOMAIN <domain name> [ AS ] <predefined type>
[ <default clause> ]
[ <domain constraint>... ]
[ <collate clause> ]

While SQL does also have a CREATE TYPE command, domains are not
among the kinds of type it can make. So that separation is
very much per spec.

I don't personally find the doc changes proposed here to be a good idea.
001 seems to add a lot of verbosity and not much else.

The intent is to add accuracy, which means verbosity given the non-obvious
choice made in the current implementation.

002 invents terms
used nowhere else in our docs, which seems more confusing than anything
else.

Fair point - was hoping it would be discussion starter.

It is very badly in need of copy-editing, as well.

I'll look at it with fresh eyes...

Also, I think the phrase you are looking for might be "type category".

Actually what I want is "Type type (typtype)" according to pg_type but that
seemed like an implementation detail that would be undesirable to use here
so I tried to give it a different name. Type category (typcategory)
already has a meaning.

Using "type definition" to mean that seems completely wrong. Deciding

that capitalized Type means something special is something I might expect
to find in one of the more abstruse philosophers, but it's not a great
idea in the Postgres manual ... especially when you then use different
terminology elsewhere.

I very well may have been inconsistent but coupled with the above point
"type of the Type" seems easier to follow compared to "type of the type" if
I were to change "type definition" to "type of the Type".

David J.

On Wed, Sep 16, 2020 at 4:42 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:

"David G. Johnston" <david.g.johnston@gmail.com> writes:

My main point here is that writing "CREATE TYPE typename AS DOMAIN" would
be expected, with the appropriate sub-specification, similar to "CREATE
TYPE typename AS RANGE".

Well, that point seems entirely invented. CREATE DOMAIN is in the
SQL standard:

And I'm writing for the user who sees that both "CREATE DOMAIN" and "CREATE
TYPE AS RANGE" exist, and that there is no "CREATE RANGE", and wonders why
if domains are simply a variant of a type, like ranges are, why doesn't
CREATE TYPE just create those as well - or, rather, are there any material
differences. I choose to include an observation that, no, they are not
materially different in terms of being abstract types.

It struck me as odd that it wasn't just CREATE TYPE AS DOMAIN and so in my
patch I thought to comment upon the oddity - and in doing so emphasize that
the DROP behavior for DOMAINS is no different than the types created by the
CREATE TYPE command.

David J.

On Tue, Sep 15, 2020 at 3:48 PM Alexander Korotkov <aekorotkov@gmail.com>
wrote:

Hi!

I've skimmed through the thread and checked the patchset. Everything
looks good, except one paragraph, which doesn't look completely clear.

+  <para>
+   This emulates the functionality provided by
+   <xref linkend="sql-createtype"/> but sets the created object's
+   <glossterm linkend="glossary-type-definition">type
definition</glossterm>
+   to domain.
+  </para>

As I get it states that CREATE DOMAIN somehow "emulates" CREATE TYPE.
Could you please, rephrase it? It looks confusing to me yet.

v5 attached, looking at this fresh and with some comments to consider.

I ended up just combining both patches into one.

I did away with the glossary changes altogether, and the invention of the
new term. I ended up limiting "type's type" to just domain usage but did a
couple of a additional tweaks that tried to treat domains as not being
actual types even though, at least in PostgreSQL, they are (at least as far
as DROP TYPE is concerned - and since I don't have any understanding of the
SQL Standard's decision to separate out create domain and create type I'll
just stick to the implementation in front of me.

David J.

st 30. 9. 2020 v 4:01 odesílatel David G. Johnston <
david.g.johnston@gmail.com> napsal:

On Tue, Sep 15, 2020 at 3:48 PM Alexander Korotkov <aekorotkov@gmail.com>
wrote:

Hi!

I've skimmed through the thread and checked the patchset. Everything
looks good, except one paragraph, which doesn't look completely clear.

+  <para>
+   This emulates the functionality provided by
+   <xref linkend="sql-createtype"/> but sets the created object's
+   <glossterm linkend="glossary-type-definition">type
definition</glossterm>
+   to domain.
+  </para>

As I get it states that CREATE DOMAIN somehow "emulates" CREATE TYPE.
Could you please, rephrase it? It looks confusing to me yet.

v5 attached, looking at this fresh and with some comments to consider.

I ended up just combining both patches into one.

I did away with the glossary changes altogether, and the invention of the
new term. I ended up limiting "type's type" to just domain usage but did a
couple of a additional tweaks that tried to treat domains as not being
actual types even though, at least in PostgreSQL, they are (at least as far
as DROP TYPE is concerned - and since I don't have any understanding of the
SQL Standard's decision to separate out create domain and create type I'll
just stick to the implementation in front of me.

+1

Pavel