Thread

1. Docs: Create table description for constraints markup fix and label tweaks

   David G. Johnston <david.g.johnston@gmail.com> — 2026-04-03T17:18:41Z

   Hi,
   
   Responding to a recent report on -general [1] I found a markup bug in the
   primary key description under create table.  0001 fixes this.
   
   The complaint itself was about using "column constraint" as a descriptive
   label in a syntax area when "column constraint" is an actual defined syntax
   label.  0002 adds the word "variant" to the six places "(table/column
   constraint)" is used in this manner.
   
   David J.
   
   [1]
   https://www.postgresql.org/message-id/CA+FnnTzeE30E4kfK4=+MLe4DBORu4CdYvPQgWUYakRxfwsbEtg@mail.gmail.com
   

2. Re: Docs: Create table description for constraints markup fix and label tweaks

   David G. Johnston <david.g.johnston@gmail.com> — 2026-04-03T17:57:27Z

   On Fri, Apr 3, 2026 at 10:18 AM David G. Johnston <
   david.g.johnston@gmail.com> wrote:
   
   > Responding to a recent report on -general [1] I found a markup bug in the
   > primary key description under create table.  0001 fixes this.
   >
   > The complaint itself was about using "column constraint" as a descriptive
   > label in a syntax area when "column constraint" is an actual defined syntax
   > label.  0002 adds the word "variant" to the six places "(table/column
   > constraint)" is used in this manner.
   >
   > [1]
   > https://www.postgresql.org/message-id/CA+FnnTzeE30E4kfK4=+MLe4DBORu4CdYvPQgWUYakRxfwsbEtg@mail.gmail.com
   >
   >
   The more you look (not having production dark mode in the core build is a
   bit annoying)...v2 attached after re-reading the original thread and
   looking around a bit more.
   
   Unique had the same sgml markup error as primary key.
   
   Also, the CF entry: https://commitfest.postgresql.org/patch/6648/
   
   David J.
   
   P.S. Reviewing this we are inconsistent as to where we use "optional"
   markup versus just literal [ ].  Even among these three locations there are
   variances - and simply literals used for optional meaning brackets.
   

3. Re: Docs: Create table description for constraints markup fix and label tweaks

   Dapeng Wang <wangdp20191008@gmail.com> — 2026-04-10T07:42:02Z

   Hi David,
   
   I reviewed both patches on the latest HEAD.
   
   0001: SGML nesting fix applied and verified - make html
   builds successfully with the corrected element nesting
   for UNIQUE and PRIMARY KEY.
   
   0002: The six "variant" label changes look good and should
   help avoid the confusion reported on -general.
   
   Looks good to me.
   
   Regards,
   Dapeng Wang
   
   David G. Johnston <david.g.johnston@gmail.com> 于2026年4月10日周五 15:04写道：
   
   > On Fri, Apr 3, 2026 at 10:18 AM David G. Johnston <
   > david.g.johnston@gmail.com> wrote:
   >
   >> Responding to a recent report on -general [1] I found a markup bug in the
   >> primary key description under create table.  0001 fixes this.
   >>
   >> The complaint itself was about using "column constraint" as a descriptive
   >> label in a syntax area when "column constraint" is an actual defined syntax
   >> label.  0002 adds the word "variant" to the six places "(table/column
   >> constraint)" is used in this manner.
   >>
   >> [1]
   >> https://www.postgresql.org/message-id/CA+FnnTzeE30E4kfK4=+MLe4DBORu4CdYvPQgWUYakRxfwsbEtg@mail.gmail.com
   >>
   >>
   > The more you look (not having production dark mode in the core build is a
   > bit annoying)...v2 attached after re-reading the original thread and
   > looking around a bit more.
   >
   > Unique had the same sgml markup error as primary key.
   >
   > Also, the CF entry: https://commitfest.postgresql.org/patch/6648/
   >
   > David J.
   >
   > P.S. Reviewing this we are inconsistent as to where we use "optional"
   > markup versus just literal [ ].  Even among these three locations there are
   > variances - and simply literals used for optional meaning brackets.
   >
   >