Docs: Distinguish table and index storage parameters in CREATE TABLE

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

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.

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.

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

--
Andreas Karlsson
Percona

On Fri, Apr 3, 2026 at 12:35 PM 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.

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.

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.

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

On Fri, Apr 3, 2026 at 3:35 PM 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
= 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.

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

On Friday, April 3, 2026, Robert Treat <rob@xzilla.net> wrote:

On Fri, Apr 3, 2026 at 3:35 PM 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
= 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.

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.