Re: Adding a LogicalRepWorker type field

Ashutosh Bapat <ashutosh.bapat.oss@gmail.com>

From: Ashutosh Bapat <ashutosh.bapat.oss@gmail.com>
To: Peter Smith <smithpb2250@gmail.com>
Cc: Amit Kapila <amit.kapila16@gmail.com>, Bharath Rupireddy <bharath.rupireddyforpostgres@gmail.com>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2023-08-03T08:50:52Z
Lists: pgsql-hackers
On Wed, Aug 2, 2023 at 12:14 PM Peter Smith <smithpb2250@gmail.com> wrote:

>
> We can't use the same names for both with/without-parameter functions
> because there is no function overloading in C. In patch v3-0001 I've
> replaced the "dual set of macros", with a single inline function of a
> different name, and one set of space-saving macros.
>

I think it's a good idea to add worker type field. Trying to deduce it
based on the contents of the structure isn't good. RelOptInfo, for example,
has RelOptKind. But RelOptInfo has become really large with members
required by all RelOptKinds crammed under the same structure. If we can
avoid that here at the beginning itself, that will be great. May be we
should create a union of type specific members while we are introducing the
type. This will also provide some protection against unrelated members
being (mis)used in the future.

-- 
Best Wishes,
Ashutosh Bapat

Commits

  1. Simplify the logical worker type checks by using the switch on worker type.

  2. Simplify determining logical replication worker types.