Обсуждение: Docs: Distinguish table and index storage parameters in CREATE TABLE
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.
Вложения
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
Re: Docs: Distinguish table and index storage parameters in CREATE TABLE
От
"David G. Johnston"
Дата:
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
Re: Docs: Distinguish table and index storage parameters in CREATE TABLE
От
"David G. Johnston"
Дата:
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.