Re: doc: improve the restriction description of using indexes on REPLICA IDENTITY FULL table.

From: Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>
To: Peter Smith <smithpb2250(at)gmail(dot)com>
Cc: Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: doc: improve the restriction description of using indexes on REPLICA IDENTITY FULL table.
Date: 2023-07-10 04:21:07
Message-ID: CAA4eK1+D4u8_wGmf47RR5bi01E8Z-EyN-YEBORDJwPXdqiCr8g@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Mon, Jul 10, 2023 at 7:55 AM Peter Smith <smithpb2250(at)gmail(dot)com> wrote:
>
> On Sat, Jul 8, 2023 at 1:49 PM Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> wrote:
> >
> > On Fri, Jul 7, 2023 at 1:36 PM Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com> wrote:
> > >
> > > I prefer the first suggestion. I've attached the updated patch.
> > >
> >
> > This looks mostly good to me but I think it would be better if we can
> > also add the information that the leftmost index column must be a
> > non-expression. So, how about: "Candidate indexes must be btree,
> > non-partial, and the leftmost index column must be a non-expression
> > and reference to a published table column (i.e. cannot consist of only
> > expressions)."?
>
> That part in parentheses ought to say "the index ..." because it is
> referring to the full INDEX, not to the leftmost column. I think this
> was missed when Sawada-san took my previous suggestion [1].
>
> IMO it doesn't sound right to say the "index column must be a
> non-expression". It is already a non-expression because it is a
> column. So I think it would be better to refer to this as an INDEX
> "field" instead of an INDEX column. Note that "field" is the same
> terminology used in the docs for CREATE INDEX [2].
>

I thought it would be better to be explicit for this case but I am
fine if Sawada-San and you prefer some other way to document it.

--
With Regards,
Amit Kapila.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Michael Paquier 2023-07-10 04:44:45 Re: pg_recvlogical prints bogus error when interrupted
Previous Message Michael Paquier 2023-07-10 04:10:45 Re: Add more sanity checks around callers of changeDependencyFor()