Subject: Docs: Distinguish table and index storage parameters in CREATE TABLE

From: "David G. Johnston" <[email-masked]>
Date: Fri, 3 Apr 2026 11:18:50 -0700

Hi,

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.

David J.

[1]
https://www.postgresql.org/message-id/flat/CA%2BFnnTyGEM-1mwxKPbwFTOodf%2BYUX%3DTxTmBPY5S%3DYh1h%3DoVY9A%40mail.gmail.com

---

From: Andreas Karlsson <[email-masked]>
Date: Fri, 3 Apr 2026 21:27:58 +0200

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.

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.

-- 
Andreas Karlsson
Percona

---

From: Andreas Karlsson <[email-masked]>
Date: Fri, 3 Apr 2026 21:35:44 +0200

> useful for the committer to knw.

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

-- 
Andreas Karlsson
Percona

---

From: "David G. Johnston" <[email-masked]>
Date: Fri, 3 Apr 2026 12:44:41 -0700

> Shouldn't also update ALTER INDEX and LATER TABLE to match?
I gave it a thought and decided there was no ambiguity to resolve on those
pages.

I'm not opposed to it but figured I'd wait for a committer to show interest
and ask the scope to be expanded to a full docs review instead of just
addressing the immediate user-reported confusion.  When I do expand the
scope on my own it seems to scare them off.

David J.

---

From: Andreas Karlsson <[email-masked]>
Date: Fri, 3 Apr 2026 21:50:30 +0200

On 4/3/26 9:44 PM, David G. Johnston wrote:
> I'm not opposed to it but figured I'd wait for a committer to show 
> interest and ask the scope to be expanded to a full docs review instead 
> of just addressing the immediate user-reported confusion.  When I do 
> expand the scope on my own it seems to scare them off.

Well, ALTER TABLE also has the same potential confusion so I think we 
should either just change CREATE TABLE and ALTER TABLE or all of CREATE 
TABLE, ALTER TABLE, CREATE INDEX and ALTER INDEX.

Just changing the two CREATE pages makes little sense when CREATE|ALTER 
TABLE are both equally problematic en my opinion.

Andreas

---

From: Robert Treat <[email-masked]>
Date: Fri, 3 Apr 2026 15:51:45 -0400

> >> 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
= 90)) with (fillfactor = 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.

> > 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

---

From: "David G. Johnston" <[email-masked]>
Date: Fri, 3 Apr 2026 20:03:35 -0700

> original discussion, but it certainly wouldn't hurt, so +1 from me.

Stretches my skills a bit but if the error message had been: (unrecognized
index storage parameter “autovacuum_enabled”) the syntax placement issue
may have been recognized working under the assumption the author knows
their intent is to modify the table (and vice-versa).

As a quick footgun prevention attempt (not a huge fan though):

Note, specifying a primary key or unique constraint as the final component
of create table makes assigning storage parameters to the wrong object more
likely.
(Added to the with clause section)

David J.