Message-ID: <83766e536155461b0e19514436fd3fbaa8e4c6a0.camel@cybertec.at>
Subject: Re: doc: create table improvements
From: Laurenz Albe <laurenz.albe@cybertec.at>
To: Chao Li <li.evan.chao@gmail.com>
Cc: "David G. Johnston" <david.g.johnston@gmail.com>, Peter Eisentraut	
 <peter@eisentraut.org>, PostgreSQL Hackers
 <pgsql-hackers@lists.postgresql.org>,  jian he <jian.universality@gmail.com>
Date: Tue, 16 Dec 2025 11:25:16 +0100
In-Reply-To: <63CD263B-E821-43BB-9B22-48C48326D663@gmail.com>
References: 
	<CAKFQuwYfMV-2SdrP-umr5SVNSqTn378BUvHsebetp5=DhT494w@mail.gmail.com>
	 <ec0bd3d2-3e15-4492-b93a-683c04ec345c@eisentraut.org>
	 <CAKFQuwYk7NsEAEsPEUdbc_gXB0OR+gZzmBjDcUSe5JZuE+d_iw@mail.gmail.com>
	 <ae5203d1f68267b1e67cfd32023ece1367689b83.camel@cybertec.at>
	 <CACJufxFgZtLENzJkZZssKdWEfHo1hk9uyC0h3JcGJJb19XRJQQ@mail.gmail.com>
	 <cbc03892163dbf67980e2863b784745517a516a5.camel@cybertec.at>
	 <3c9aabf667db65e757dddbdad1a13d623170e970.camel@cybertec.at>
	 <CAKFQuwaEo8dxUmVsmjkb4WBEtKHUazeaN1pwsbDpLsFdANDAkQ@mail.gmail.com>
	 <ab574da206f7cb0db340671d88eff4ae9d66e450.camel@cybertec.at>
	 <63CD263B-E821-43BB-9B22-48C48326D663@gmail.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
User-Agent: Evolution 3.56.2 (3.56.2-2.fc42) 
MIME-Version: 1.0
Archived-At: 
 <https://www.postgresql.org/message-id/83766e536155461b0e19514436fd3fbaa8e4c6a0.camel%40cybertec.at>
Precedence: bulk

On Tue, 2025-12-16 at 10:14 +0800, Chao Li wrote:
> > On Oct 23, 2025, at 12:43, Laurenz Albe <laurenz.albe@cybertec.at> wrot=
e:
> > <v4-0001-Unclutter-CREATE-TABLE-synopsis.patch>
>=20
> Overall the change looks good to me. I have only one comment about the na=
ming
> of =E2=80=9Coversize_storage=E2=80=9D. Why not just =E2=80=9Cstorage_para=
meters=E2=80=9D or similar that
> sounds more straightforward?

"Storage parameter" is not a good idea, because we use that term for
something else: CREATE TABLE ... WITH (storage_parameter =3D value)

I think "oversize_storage" expresses well what is regulated here.
I'm open to "toast_options" or similar as an alternative, but I think
it might be better to avoid jargon - not everybody reading that page
will be familiar with the term.

Yours,
Laurenz Albe