DROP relation IF EXISTS Docs and Tests - Bug Fix

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
18 messages Options
Reply | Threaded
Open this post in threaded view
|

DROP relation IF EXISTS Docs and Tests - Bug Fix

David G Johnston
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.

David J.


drop-if-exists-docs-and-tests-v1.patch (24K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

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

Tom Lane-2
"David G. Johnston" <[hidden email]> 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


Reply | Threaded
Open this post in threaded view
|

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

David G Johnston
On Wed, Jun 17, 2020 at 4:32 PM Tom Lane <[hidden email]> wrote:
"David G. Johnston" <[hidden email]> 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.

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.

Reply | Threaded
Open this post in threaded view
|

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

Pavel Stehule
In reply to this post by David G Johnston
Hi

čt 18. 6. 2020 v 0:47 odesílatel David G. Johnston <[hidden email]> 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



 

David J.

Reply | Threaded
Open this post in threaded view
|

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

Pavel Stehule


po 13. 7. 2020 v 11:11 odesílatel Pavel Stehule <[hidden email]> napsal:
Hi

čt 18. 6. 2020 v 0:47 odesílatel David G. Johnston <[hidden email]> 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=#


Regards

Pavel



 

David J.

Reply | Threaded
Open this post in threaded view
|

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

David G Johnston
In reply to this post by Pavel Stehule
On Mon, Jul 13, 2020 at 2:12 AM Pavel Stehule <[hidden email]> 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.


drop-if-exists-docs-and-tasks-v2.diff (32K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

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

Pavel Stehule


út 14. 7. 2020 v 0:37 odesílatel David G. Johnston <[hidden email]> napsal:
On Mon, Jul 13, 2020 at 2:12 AM Pavel Stehule <[hidden email]> 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.

Reply | Threaded
Open this post in threaded view
|

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

Justin Pryzby
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 <[hidden email]> napsal:
> > On Mon, Jul 13, 2020 at 2:12 AM Pavel Stehule <[hidden email]> 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


Reply | Threaded
Open this post in threaded view
|

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

David G Johnston
On Tue, Jul 14, 2020 at 5:40 AM Justin Pryzby <[hidden email]> 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 <[hidden email]> napsal:
> > On Mon, Jul 13, 2020 at 2:12 AM Pavel Stehule <[hidden email]> 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.
Reply | Threaded
Open this post in threaded view
|

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

Pavel Stehule


út 14. 7. 2020 v 15:55 odesílatel David G. Johnston <[hidden email]> napsal:
On Tue, Jul 14, 2020 at 5:40 AM Justin Pryzby <[hidden email]> 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 <[hidden email]> napsal:
> > On Mon, Jul 13, 2020 at 2:12 AM Pavel Stehule <[hidden email]> 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


David J.

drop-if-exists-docs-and-tasks-v3.diff (32K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

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

David G Johnston
On Tue, Jul 14, 2020 at 6:56 AM Pavel Stehule <[hidden email]> wrote:
út 14. 7. 2020 v 15:55 odesílatel David G. Johnston <[hidden email]> 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.
Reply | Threaded
Open this post in threaded view
|

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

Pavel Stehule


út 14. 7. 2020 v 16:09 odesílatel David G. Johnston <[hidden email]> napsal:
On Tue, Jul 14, 2020 at 6:56 AM Pavel Stehule <[hidden email]> wrote:
út 14. 7. 2020 v 15:55 odesílatel David G. Johnston <[hidden email]> 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.


David J.
Reply | Threaded
Open this post in threaded view
|

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

David G Johnston
On Tue, Jul 14, 2020 at 7:21 AM Pavel Stehule <[hidden email]> wrote:
út 14. 7. 2020 v 16:09 odesílatel David G. Johnston <[hidden email]> napsal:
On Tue, Jul 14, 2020 at 6:56 AM Pavel Stehule <[hidden email]> wrote:
út 14. 7. 2020 v 15:55 odesílatel David G. Johnston <[hidden email]> 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.

001-drop-if-exists-docs-and-tests-v4.patch (29K) Download Attachment
002-types-glossary-v4.patch (10K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

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

Alexander Korotkov-4
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


Reply | Threaded
Open this post in threaded view
|

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

David G Johnston
On Tue, Sep 15, 2020 at 3:48 PM Alexander Korotkov <[hidden email]> 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.

Reply | Threaded
Open this post in threaded view
|

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

Tom Lane-2
"David G. Johnston" <[hidden email]> 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


Reply | Threaded
Open this post in threaded view
|

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

David G Johnston
On Wed, Sep 16, 2020 at 4:42 PM Tom Lane <[hidden email]> wrote:
"David G. Johnston" <[hidden email]> 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.

Reply | Threaded
Open this post in threaded view
|

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

David G Johnston
In reply to this post by Tom Lane-2
On Wed, Sep 16, 2020 at 4:42 PM Tom Lane <[hidden email]> wrote:
"David G. Johnston" <[hidden email]> 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.