Re-order "disable_on_error" in tab-complete COMPLETE_WITH

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.

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.

--
Euler Taveira
EDB https://www.enterprisedb.com/

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