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
Attachments:
v1-0001-Re-order-disable_on_error-in-tab-complete-COMPLET.patchapplication/octet-stream; name=v1-0001-Re-order-disable_on_error-in-tab-complete-COMPLET.patchDownload
From 006ff2654c963c0f89759e652c5213e1661356a9 Mon Sep 17 00:00:00 2001
From: Peter Smith <peter.b.smith@fujitsu.com>
Date: Mon, 4 Jul 2022 17:21:36 +1000
Subject: [PATCH v1] Re-order disable_on_error in tab-complete COMPLETE_WITH
By convention the tab-complete subscription parameters are listed
in the COMPLETE_WITH lists in alphabetical order, but when the
"disable_on_error" parameter was implemented this was not
done.
This patch just tidies that up; there is no functional change.
---
src/bin/psql/tab-complete.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/src/bin/psql/tab-complete.c b/src/bin/psql/tab-complete.c
index c5cafe6..e572f58 100644
--- a/src/bin/psql/tab-complete.c
+++ b/src/bin/psql/tab-complete.c
@@ -1873,7 +1873,7 @@ psql_completion(const char *text, int start, int end)
COMPLETE_WITH("(", "PUBLICATION");
/* ALTER SUBSCRIPTION <name> SET ( */
else if (HeadMatches("ALTER", "SUBSCRIPTION", MatchAny) && TailMatches("SET", "("))
- COMPLETE_WITH("binary", "slot_name", "streaming", "synchronous_commit", "disable_on_error");
+ COMPLETE_WITH("binary", "disable_on_error", "slot_name", "streaming", "synchronous_commit");
/* ALTER SUBSCRIPTION <name> SKIP ( */
else if (HeadMatches("ALTER", "SUBSCRIPTION", MatchAny) && TailMatches("SKIP", "("))
COMPLETE_WITH("lsn");
@@ -3152,8 +3152,8 @@ psql_completion(const char *text, int start, int end)
/* Complete "CREATE SUBSCRIPTION <name> ... WITH ( <opt>" */
else if (HeadMatches("CREATE", "SUBSCRIPTION") && TailMatches("WITH", "("))
COMPLETE_WITH("binary", "connect", "copy_data", "create_slot",
- "enabled", "slot_name", "streaming",
- "synchronous_commit", "two_phase", "disable_on_error");
+ "disable_on_error", "enabled", "slot_name", "streaming",
+ "synchronous_commit", "two_phase");
/* CREATE TRIGGER --- is allowed inside CREATE SCHEMA, so use TailMatches */
--
1.8.3.1
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