Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1vbVJ1-006BoC-1j for pgsql-hackers@arkaria.postgresql.org; Fri, 02 Jan 2026 02:54:24 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.96) (envelope-from ) id 1vbVIz-009FDm-19 for pgsql-hackers@arkaria.postgresql.org; Fri, 02 Jan 2026 02:54:22 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1vbVIy-009FDd-33 for pgsql-hackers@lists.postgresql.org; Fri, 02 Jan 2026 02:54:21 +0000 Received: from mail-vk1-xa2a.google.com ([2607:f8b0:4864:20::a2a]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96) (envelope-from ) id 1vbVIy-003kVn-04 for pgsql-hackers@lists.postgresql.org; Fri, 02 Jan 2026 02:54:20 +0000 Received: by mail-vk1-xa2a.google.com with SMTP id 71dfb90a1353d-5598b58d816so8850824e0c.3 for ; Thu, 01 Jan 2026 18:54:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=xzilla-net.20230601.gappssmtp.com; s=20230601; t=1767322459; x=1767927259; darn=lists.postgresql.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=X1oyYUwha46cLvcsGnumD+MYl6xlBGOWwxxjkY025cY=; b=hwoVINh8sEIkkH7blqasGITURPgl+rLL5IWegGgXvjfi79q1ILfhk23TCqdAnkq0wT oMh/NzmfnznKstar5iHVFtGYqiEsw32qNc5XmkHI8OfDKKdIzETy4K5hwxZIIW7bbtek F/I95MsQQ8Fu2JBsM3d5cCC+TbKK+lgaTP2DC/3MFpSTOfk2kb4XEB404gyxnFHt9YJJ fru1DqKKsxJImuo/hDnosh8jFRvMKmEVOOjWLAUdC1yPD+4l614oa8ca4wpZ2GT2QrGn V9O2Paf7sXdO/29bqL+zWXSLcVKtEskZwta0whxwk+ZqDlzRKV+SalbE8Q/8a9dT0Lmi m7KQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1767322459; x=1767927259; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=X1oyYUwha46cLvcsGnumD+MYl6xlBGOWwxxjkY025cY=; b=hnStA+tiMN0e3y4fvgyessKgJjC71M095hDWSs52GLW9lWKvKPHVnXc03QhXT+ukQr R0uMtt9LIByvdTQXAVHlnL4c+3Km4E08KFBB8GBv7TGNXjxEq7V45FuEJDtnbMbJQCC9 577OyNhwKM+KlvOHOieTuAyxkoGGi4OxObZJFC+/5JhDMIBtvdRGFWs1lnlLogWvcPMD QabRB0duKFDYIxeD1aOCTEsQLYzxsBFrrrimysYBu1Zxs6JwiS59G1sUpQ3l4hrwXkuS Y39PQ0xxBk/wYaRE7vOGWTCCJW9jIMT3Vdwm/lQLzI05NxYfp5lGKWpJ2pzVSODkdrvY 08Rw== X-Gm-Message-State: AOJu0YzLQuhIsDrnIBGgwxNj8JL3slgKzV8jChUrYLzsweX5Q6GCxIht 0U4PJwnL7KKodd0Jm8j9JVNqejvxZSFhH/Q68lD4zQ6Kf3Cce/LEVqiiGR7WDgPvlKg+DVzCxNg L7u8U/7xkI1RlyqFWKII6NFI1EULCV6AC2MONp0hI2g== X-Gm-Gg: AY/fxX5mVK4b3goxcpcNN579WRBFhKzvoNUkNXaTb0EKCMp/i/N3BMze/Gb0EdxQRD8 fJvuDUn4iZYqvKW6Eb9ObxqqS5dOUvSNKM+Qndqfhr50yJB4nVTWMIHH1sOhMMY9DQNNVd8jQXN dqT/y/zfGd8W0qLVENlb5nPb/vWNCVJw2YjOLjLjyPOLV6tV9OieZsCc8G3+/vDFQ7jwj+IjoPT zJJQejQ8q7XH2j4p1kClfSfuKFMLzpe0fk6JBy3+ztBlkRlPpLBIW8GjBYOKz5jZYsVHs0= X-Google-Smtp-Source: AGHT+IFZcX6AvU59J24FhUSpTkzxmkEbEnTMDaxsYupNoKUirFyY1Z8K8Q1g2mYciw0sA4/VkOxZNzzTaoosVem8mDM= X-Received: by 2002:a05:6122:a1b:b0:55b:14ec:6fb9 with SMTP id 71dfb90a1353d-5615be767d9mr11658680e0c.14.1767322458855; Thu, 01 Jan 2026 18:54:18 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Robert Treat Date: Thu, 1 Jan 2026 21:54:06 -0500 X-Gm-Features: AQt7F2rBu2oD7gvRwV7fmS26370MIJ2Tzp5tw4LK43hhvkRoi6-3-RZ3gXajNdw Message-ID: Subject: Re: DOC: fixes multiple errors in alter table doc To: Chao Li Cc: Postgres hackers Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On Thu, Dec 18, 2025 at 2:22=E2=80=AFAM Chao Li wr= ote: > > Hi Hacker, > > While working on a patch these days, my eyes are on the =E2=80=9Calter ta= ble=E2=80=9D doc, and found multiple errors: > > 1. Several sub-commands are missed in the top =E2=80=9Caction=E2=80=9D li= st: > > * ALTER COLUMN SET > * ALTER COLUMN RESTART I believe these are covered by the line above them: ALTER [ COLUMN ] column_name { SET GENERATED { ALWAYS | BY DEFAULT } | SET sequence_option | RESTART [ [ WITH ] restart ] } [...] > * RENAME This is covered by the 4th line ALTER TABLE [ IF EXISTS ] name RENAME TO new_name > * SET SCHEMA 5th option... ALTER TABLE [ IF EXISTS ] name SET SCHEMA new_schema > * ATTACH PARTITION > * DETACH PARTITION > * MERGE PARTITION > * SPLIT PARTITION > And the above are the 7,8,9,10th options at the top. > 2. In sub-command details section, "ADD COLUMN [ IF NOT EXISTS ]=E2=80=9D= missed =E2=80=9C[]" with =E2=80=9CCOLUMN=E2=80=9D, which is misleading, be= cause =E2=80=9CCOLUMN=E2=80=9D is actually optional. > Seems technically correct and potentially useful, and I see you handled this for the DROP COLUMN variant as well, so I could see a +1 on this one. > 3. For all =E2=80=9Calter column=E2=80=9D sub-commands, "ALTER [ COLUMN ]= =E2=80=9D are omitted, which is also confusing, because none of other sub-c= ommands omit their prefix part. > Hmm... I'm curious what you find confusing about this. Is the confusion in trying to find or understand the information presented, or confusing as to why it isn't all documented the same way? The downside of your "fix" is that this introduces a lot of extra text that is more or less noise, especially for folks trying to skim the documents looking for very specific command references. And while I agree that we aren't 100% consistent on this within the ALTER TABLE subcommands, we use this same mixed pattern of omission on other pages (see ALTER TYPE for instance). If we were to insist on making this consistent here, I think we'd probably need to look at other pages as well and evaluate or update them too. I'm not sure that would be an improvement though. Robert Treat https://xzilla.net