INDEX with optional storage parameter value

Started by PG Bug reporting formalmost 6 years ago7 messagesdocs
Jump to latest
#1PG Bug reporting form
noreply@postgresql.org

The following documentation comment has been logged on the website:

Page: https://www.postgresql.org/docs/12/sql-createindex.html
Description:

Hello!
I noticed an slight inaccuracy in the documentation for CREATE INDEX and
ALTER INDEX:

CREATE INDEX ... [ WITH ( storage_parameter = value [, ... ] ) ]
ALTER INDEX [ IF EXISTS ] name SET ( storage_parameter = value [, ... ] )

In indices, as in tables, you can omit the вoolean value for a parameter.
For example:

CREATE INDEX ON public.testtable USING GIN (c1) WITH (fastupdate);
ALTER INDEX testtable_c1_idx SET (fastupdate);

It might be more correct to use the construct from CREATE TABLE:

storage_parameter [= value] [, ... ]

#2Bruce Momjian
bruce@momjian.us
In reply to: PG Bug reporting form (#1)
Re: INDEX with optional storage parameter value

On Mon, Jun 22, 2020 at 01:13:52PM +0000, PG Doc comments form wrote:

The following documentation comment has been logged on the website:

Page: https://www.postgresql.org/docs/12/sql-createindex.html
Description:

Hello!
I noticed an slight inaccuracy in the documentation for CREATE INDEX and
ALTER INDEX:

CREATE INDEX ... [ WITH ( storage_parameter = value [, ... ] ) ]
ALTER INDEX [ IF EXISTS ] name SET ( storage_parameter = value [, ... ] )

In indices, as in tables, you can omit the вoolean value for a parameter.
For example:

CREATE INDEX ON public.testtable USING GIN (c1) WITH (fastupdate);
ALTER INDEX testtable_c1_idx SET (fastupdate);

It might be more correct to use the construct from CREATE TABLE:

storage_parameter [= value] [, ... ]

Yes, I see that:

CREATE TABLE testtable (c1 JSONB);
CREATE INDEX ON public.testtable USING GIN (c1) WITH (fastupdate = true);
CREATE INDEX ON public.testtable USING GIN (c1) WITH (fastupdate = false);
CREATE INDEX ON public.testtable USING GIN (c1) WITH (fastupdate);
\d testtable
Table "public.testtable"
Column | Type | Collation | Nullable | Default
--------+-------+-----------+----------+---------
c1 | jsonb | | |
Indexes:
"testtable_c1_idx" gin (c1) WITH (fastupdate='true')
"testtable_c1_idx1" gin (c1) WITH (fastupdate='false')
"testtable_c1_idx2" gin (c1) WITH (fastupdate='true')

I found a few more places that also didn't properly document this;
patch attached.

--
Bruce Momjian <bruce@momjian.us> https://momjian.us
EnterpriseDB https://enterprisedb.com

The usefulness of a cup is in its emptiness, Bruce Lee

Attachments:

storage.difftext/x-diff; charset=us-asciiDownload+6-6
#3Michael Paquier
michael@paquier.xyz
In reply to: Bruce Momjian (#2)
Re: INDEX with optional storage parameter value

On Sat, Jun 27, 2020 at 05:14:23PM -0400, Bruce Momjian wrote:

I found a few more places that also didn't properly document this;
patch attached.

Good catch! I am not seeing any missing spots, so this looks good to
me. You are planning a backpatch, right?
--
Michael

#4Laurenz Albe
laurenz.albe@cybertec.at
In reply to: Bruce Momjian (#2)
Re: INDEX with optional storage parameter value

On Sat, 2020-06-27 at 17:14 -0400, Bruce Momjian wrote:

I noticed an slight inaccuracy in the documentation for CREATE INDEX and
ALTER INDEX:

CREATE INDEX ... [ WITH ( storage_parameter = value [, ... ] ) ]
ALTER INDEX [ IF EXISTS ] name SET ( storage_parameter = value [, ... ] )

In indices, as in tables, you can omit the вoolean value for a parameter.
For example:

CREATE INDEX ON public.testtable USING GIN (c1) WITH (fastupdate);
ALTER INDEX testtable_c1_idx SET (fastupdate);

It might be more correct to use the construct from CREATE TABLE:

storage_parameter [= value] [, ... ]

I found a few more places that also didn't properly document this;
patch attached.

Looks good.
Perhaps it is worth explaining this explicitly, as in the attached.

Yours,
Laurenz Albe

Attachments:

0001-Document-that-values-can-be-omitted-for-boolean-stor.patchtext/x-patch; charset=UTF-8; name=0001-Document-that-values-can-be-omitted-for-boolean-stor.patchDownload+18-7
#5Bruce Momjian
bruce@momjian.us
In reply to: Michael Paquier (#3)
Re: INDEX with optional storage parameter value

On Mon, Jun 29, 2020 at 04:18:58PM +0900, Michael Paquier wrote:

On Sat, Jun 27, 2020 at 05:14:23PM -0400, Bruce Momjian wrote:

I found a few more places that also didn't properly document this;
patch attached.

Good catch! I am not seeing any missing spots, so this looks good to
me. You are planning a backpatch, right?

Yes, backpatch. I found the pattern of areas needing fixes to be quite
odd. ;-)

--
Bruce Momjian <bruce@momjian.us> https://momjian.us
EnterpriseDB https://enterprisedb.com

The usefulness of a cup is in its emptiness, Bruce Lee

#6Bruce Momjian
bruce@momjian.us
In reply to: Laurenz Albe (#4)
Re: INDEX with optional storage parameter value

On Mon, Jun 29, 2020 at 09:26:57AM +0200, Laurenz Albe wrote:

On Sat, 2020-06-27 at 17:14 -0400, Bruce Momjian wrote:

I noticed an slight inaccuracy in the documentation for CREATE INDEX and
ALTER INDEX:

CREATE INDEX ... [ WITH ( storage_parameter = value [, ... ] ) ]
ALTER INDEX [ IF EXISTS ] name SET ( storage_parameter = value [, ... ] )

In indices, as in tables, you can omit the вoolean value for a parameter.
For example:

CREATE INDEX ON public.testtable USING GIN (c1) WITH (fastupdate);
ALTER INDEX testtable_c1_idx SET (fastupdate);

It might be more correct to use the construct from CREATE TABLE:

storage_parameter [= value] [, ... ]

I found a few more places that also didn't properly document this;
patch attached.

Looks good.
Perhaps it is worth explaining this explicitly, as in the attached.

Uh, I considered this, but it seems unnecessary at this time.

--
Bruce Momjian <bruce@momjian.us> https://momjian.us
EnterpriseDB https://enterprisedb.com

The usefulness of a cup is in its emptiness, Bruce Lee

#7Bruce Momjian
bruce@momjian.us
In reply to: Bruce Momjian (#5)
Re: INDEX with optional storage parameter value

On Mon, Jun 29, 2020 at 09:53:17AM -0400, Bruce Momjian wrote:

On Mon, Jun 29, 2020 at 04:18:58PM +0900, Michael Paquier wrote:

On Sat, Jun 27, 2020 at 05:14:23PM -0400, Bruce Momjian wrote:

I found a few more places that also didn't properly document this;
patch attached.

Good catch! I am not seeing any missing spots, so this looks good to
me. You are planning a backpatch, right?

Yes, backpatch. I found the pattern of areas needing fixes to be quite
odd. ;-)

Patch applied through 9.5.

--
Bruce Momjian <bruce@momjian.us> https://momjian.us
EnterpriseDB https://enterprisedb.com

The usefulness of a cup is in its emptiness, Bruce Lee