Обсуждение: INDEX with optional storage parameter value

Поиск
Список
Период
Сортировка

INDEX with optional storage parameter value

От
PG Doc comments form
Дата:
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] [, ... ]

Re: INDEX with optional storage parameter value

От
Bruce Momjian
Дата:
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


Вложения

Re: INDEX with optional storage parameter value

От
Michael Paquier
Дата:
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

Вложения

Re: INDEX with optional storage parameter value

От
Laurenz Albe
Дата:
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

Вложения

Re: INDEX with optional storage parameter value

От
Bruce Momjian
Дата:
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




Re: INDEX with optional storage parameter value

От
Bruce Momjian
Дата:
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




Re: INDEX with optional storage parameter value

От
Bruce Momjian
Дата:
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