Re: GetSubscriptionRelations declares too many scan keys
Peter Smith <smithpb2250@gmail.com>
From: Peter Smith <smithpb2250@gmail.com>
To: Bharath Rupireddy <bharath.rupireddyforpostgres@gmail.com>
Cc: PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2021-05-10T09:09:29Z
Lists: pgsql-hackers
On Mon, May 10, 2021 at 6:09 PM Bharath Rupireddy <bharath.rupireddyforpostgres@gmail.com> wrote: > > On Mon, May 10, 2021 at 12:36 PM Peter Smith <smithpb2250@gmail.com> wrote: > > > > The function GetSubscriptionRelations was declaring ScanKeyData > > skey[2]; but actually > > only uses 1 scan key. It seems like the code was cut/paste from other > > nearby functions > > which really are using 2 keys. > > > > PSA a trivial patch to declare the correct number of keys for this function. > > +1 for the change. It looks like a cut/paste type introduced by the > commit 7c4f52409a. > > A comment on the patch: why do we need to declare an array of 1 > element ScanKeyData skey[1];? Instead, can we just do ScanKeyData > skey;? IMO declaring skey[1] is better because then the code can share the same pattern as every other ScanData skey[n] code. Please search PG source code for "ScanData skey[1];" - there are dozens of precedents where other people felt the same as me for declaring single keys. -------- Kind Regards, Peter Smith. Fujitsu Australia
Commits
-
Simplify one use of ScanKey in pg_subscription.c
- e6ccd1ce1644 14.0 landed
-
Logical replication support for initial data copy
- 7c4f52409a8c 10.0 cited