Re: Add A Glossary - Mailing list pgsql-hackers

From Corey Huinker
Subject Re: Add A Glossary
Date
Msg-id CADkLM=fwtE-TCU7sRnvaE74z12kOp_A+CdUwMr7aZt39pXbh6A@mail.gmail.com
Whole thread Raw
In response to Re: Add A Glossary  (Jürgen Purtz <juergen@purtz.de>)
Responses Re: Add A Glossary  (Alvaro Herrera <alvherre@2ndquadrant.com>)
List pgsql-hackers
On Fri, Mar 13, 2020 at 12:18 AM Jürgen Purtz <juergen@purtz.de> wrote:

The statement that names of schema objects are unique isn't strictly true, just mostly true. Take the case of a unique constraints.

Concerning CONSTRAINTS you are right. Constraints seems to be an exception:

  • Their name belongs to a schema, but are not necessarily unique within this context: https://www.postgresql.org/docs/current/catalog-pg-constraint.html.
  • There is a UNIQUE index within the system catalog pg_constraints:  "pg_constraint_conrelid_contypid_conname_index" UNIQUE, btree (conrelid, contypid, conname), which expresses that names are unique within the context of a table/constraint-type. Nevertheless tests have shown that some stronger restrictions exists across table-boarders (,which seems to be implemented in CREATE statements - or as a consequence of your mentioned correlation between constraint and index ?).

I hope that there are no more such exception to the global rule 'object names in a schema are unique': https://www.postgresql.org/docs/current/sql-createschema.html

This facts must be mentioned as a short note in glossary and in more detail in the later patch about the architecture.


I did what I could to address the near uniqueness, as well as incorporate your earlier edits into this new, squashed patch attached.
 
Attachment

pgsql-hackers by date:

Previous
From: Amit Langote
Date:
Subject: Re: pg_stat_progress_basebackup - progress reporting forpg_basebackup, in the server side
Next
From: Alvaro Herrera
Date:
Subject: Re: pg_stat_progress_basebackup - progress reporting forpg_basebackup, in the server side