Thread: Re-order "disable_on_error" in tab-complete COMPLETE_WITH

Hi.

By convention, the tab-complete logical replication subscription
parameters are listed in the COMPLETE_WITH lists in alphabetical
order, but when the "disable_on_error" parameter was added this was
not done.

This patch just tidies that up; there is no functional change.

PSA

------
Kind Regards,
Peter Smith.
Fujitsu Australia

On Mon, Jul 4, 2022 at 1:07 PM Peter Smith <smithpb2250@gmail.com> wrote:
>
> By convention, the tab-complete logical replication subscription
> parameters are listed in the COMPLETE_WITH lists in alphabetical
> order, but when the "disable_on_error" parameter was added this was
> not done.
>

Yeah, it seems we have overlooked this point. I think we can do this
just for HEAD but as the feature is introduced in PG-15 so there is no
harm in pushing it to PG-15 as well especially because it is a
straightforward change. What do you or others think?

-- 
With Regards,
Amit Kapila.

Yeah, it seems we have overlooked this point. I think we can do this

just for HEAD but as the feature is introduced in PG-15 so there is no

harm in pushing it to PG-15 as well especially because it is a

straightforward change. What do you or others think?

On Mon, Jul 4, 2022 at 10:29 PM Euler Taveira <euler@eulerto.com> wrote:
>
> On Mon, Jul 4, 2022, at 5:37 AM, Amit Kapila wrote:
>
> Yeah, it seems we have overlooked this point. I think we can do this
> just for HEAD but as the feature is introduced in PG-15 so there is no
> harm in pushing it to PG-15 as well especially because it is a
> straightforward change. What do you or others think?
>
> No objection. It is a good thing for future backpatches.
>

Since there is no function change or bugfix here I thought it was only
applicable for HEAD. This change is almost in the same category as a
code comment typo patch - do those normally get backpatched? - maybe
follow the same convention here. OTOH, if you think it may be helpful
for future backpatches then I am also fine if you wanted to push it to
PG15.

------
Kind Regards,
Peter Smith.
Fujitsu Australia

On Tue, Jul 5, 2022 at 4:03 AM Peter Smith <smithpb2250@gmail.com> wrote:
>
> On Mon, Jul 4, 2022 at 10:29 PM Euler Taveira <euler@eulerto.com> wrote:
> >
> > On Mon, Jul 4, 2022, at 5:37 AM, Amit Kapila wrote:
> >
> > Yeah, it seems we have overlooked this point. I think we can do this
> > just for HEAD but as the feature is introduced in PG-15 so there is no
> > harm in pushing it to PG-15 as well especially because it is a
> > straightforward change. What do you or others think?
> >
> > No objection. It is a good thing for future backpatches.
> >
>
> Since there is no function change or bugfix here I thought it was only
> applicable for HEAD. This change is almost in the same category as a
> code comment typo patch - do those normally get backpatched? - maybe
> follow the same convention here. OTOH, if you think it may be helpful
> for future backpatches then I am also fine if you wanted to push it to
> PG15.
>

It can help if there is any bug-fix in the same code path or if some
other code adjustment in the same area is required in the back branch.
I feel the chances of both are less but I just wanted to keep the code
consistent for such a possibility. Anyway, I'll wait for a day or so
and see if anyone has objections to it.

-- 
With Regards,
Amit Kapila.

On Tuesday, July 5, 2022 1:05 PM Amit Kapila <amit.kapila16@gmail.com> wrote:
> On Tue, Jul 5, 2022 at 4:03 AM Peter Smith <smithpb2250@gmail.com> wrote:
> >
> > On Mon, Jul 4, 2022 at 10:29 PM Euler Taveira <euler@eulerto.com> wrote:
> > >
> > > On Mon, Jul 4, 2022, at 5:37 AM, Amit Kapila wrote:
> > >
> > > Yeah, it seems we have overlooked this point. I think we can do this
> > > just for HEAD but as the feature is introduced in PG-15 so there is
> > > no harm in pushing it to PG-15 as well especially because it is a
> > > straightforward change. What do you or others think?
> > >
> > > No objection. It is a good thing for future backpatches.
> > >
> >
> > Since there is no function change or bugfix here I thought it was only
> > applicable for HEAD. This change is almost in the same category as a
> > code comment typo patch - do those normally get backpatched? - maybe
> > follow the same convention here. OTOH, if you think it may be helpful
> > for future backpatches then I am also fine if you wanted to push it to
> > PG15.
> >
> 
> It can help if there is any bug-fix in the same code path or if some other code
> adjustment in the same area is required in the back branch.
> I feel the chances of both are less but I just wanted to keep the code consistent
> for such a possibility. Anyway, I'll wait for a day or so and see if anyone has
> objections to it.
Thank you all for catching and discussing this fix.

I also agree with pushing it to PG-15 for comfortability of future backpatches.



Best Regards,
    Takamichi Osumi

On Wed, Jul 06, 2022 at 02:48:07AM +0000, osumi.takamichi@fujitsu.com wrote:
> On Tuesday, July 5, 2022 1:05 PM Amit Kapila <amit.kapila16@gmail.com> wrote:
>> It can help if there is any bug-fix in the same code path or if some other code
>> adjustment in the same area is required in the back branch.
>> I feel the chances of both are less but I just wanted to keep the code consistent
>> for such a possibility. Anyway, I'll wait for a day or so and see if anyone has
>> objections to it.
>
> I also agree with pushing it to PG-15 for comfortability of future backpatches.

Yeah, backpatching that is just but fine.
--
Michael

FYI, I confirmed the same patch applies and works OK for tags/REL_15_BETA2.

------

[postgres@CentOS7-x64 ~]$ psql --version
psql (PostgreSQL) 15beta2
[postgres@CentOS7-x64 ~]$ psql
psql (15beta2)
Type "help" for help.

postgres=# create subscription mysub connection 'blah' publication
mypub with ( <press-tab>
BINARY              COPY_DATA           DISABLE_ON_ERROR    SLOT_NAME
         SYNCHRONOUS_COMMIT
CONNECT             CREATE_SLOT         ENABLED             STREAMING
         TWO_PHASE
postgres=# create subscription mysub connection 'blah' publication mypub with (

------
Kind Regards,
Peter Smith.
Fujitsu Australia