MIME-Version: 1.0
References: 
 <CAKFQuwYe1vf7k+gx_f5ny1mpz_CrhMhaa_NgVb-87_=DHj3JEw@mail.gmail.com>
 <e7286453-7d8c-460d-b6fa-95df54c3ca13@proxel.se>
 <f828ab0a-0231-4673-a407-e550cdc549bd@proxel.se>
In-Reply-To: <f828ab0a-0231-4673-a407-e550cdc549bd@proxel.se>
From: Robert Treat <rob@xzilla.net>
Date: Fri, 3 Apr 2026 15:51:45 -0400
Message-ID: 
 <CABV9wwP-A7XhKfJTJ=ryMV2mfQtzDRsQW73K6+ZvFP56s31j3A@mail.gmail.com>
Subject: Re: Docs: Distinguish table and index storage parameters in CREATE
 TABLE
To: Andreas Karlsson <andreas@proxel.se>
Cc: "David G. Johnston" <david.g.johnston@gmail.com>,
	PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: 
 <https://www.postgresql.org/message-id/CABV9wwP-A7XhKfJTJ%3DryMV2mfQtzDRsQW73K6%2BZvFP56s31j3A%40mail.gmail.com>
Precedence: bulk

On Fri, Apr 3, 2026 at 3:35=E2=80=AFPM Andreas Karlsson <andreas@proxel.se>=
 wrote:
> On 4/3/26 9:27 PM, Andreas Karlsson wrote:
> > On 4/3/26 8:18 PM, David G. Johnston wrote:
> >> Per the discussion on -general [1] I propose that we stop using the
> >> generic label storage_parameter on the create table reference page and
> >> instead set up proper labels for table and index variants.
> >

It's sort of interesting that no one in the above discussion gave an
example like:
create table t (c int, constraint pk primary key (c) with (fillfactor
=3D 90)) with (fillfactor =3D 100);
and pointing out that where you put the parameter changes what it
effects, so I'm a little skeptical that this patch would help the
original discussion, but it certainly wouldn't hurt, so +1 from me.

> > Nice patch, I like these changes! But you forgot to mention that you
> > added the index storage parameters as in <indexterm>. Not sure if it is
> > worth sending a new version of the patch for but something probably
> > useful for the committer to knw.
>

Looking through the index on my local generated doc build, this seems
like an improvement.

> Shouldn't also update ALTER INDEX and LATER TABLE to match?
>

I was thinking the same thing. While we only have one version of the
term on those pages, ISTM that we ought to use the terms consistently
if we are going to change them in one place. A quick search also seems
to indicate that this would expand the change to a number of other
pages too though (materialized views and such).

Robert Treat
https://xzilla.net