Re: row filtering for logical replication

On Fri, Jan 7, 2022 at 9:44 AM Amit Kapila <amit.kapila16@gmail.com> wrote:

>

> On Thu, Jan 6, 2022 at 6:42 PM Euler Taveira <euler@eulerto.com> wrote:

> >

> > IMO we shouldn't reuse ReorderBufferChangeType. For a long-term solution, it is

> > fragile. ReorderBufferChangeType has values that do not matter for row filter

> > and it relies on the fact that REORDER_BUFFER_CHANGE_INSERT,

> > REORDER_BUFFER_CHANGE_UPDATE and REORDER_BUFFER_CHANGE_DELETE are the first 3

> > values from the enum, otherwise, it breaks rfnodes and no_filters in

> > pgoutput_row_filter().

> >

>

> I think you mean to say it will break in pgoutput_row_filter_init(). I

> see your point but OTOH, if we do what you are suggesting then don't

> we need an additional mapping between ReorderBufferChangeType and

> RowFilterPublishAction as row filter and pgoutput_change API need to

> use those values.

>

Can't we use 0,1,2 as indexes for rfnodes/no_filters based on change

type as they are local variables as that will avoid the fragileness

you are worried about. I am slightly hesitant to introduce new enum

when we are already using reorder buffer change type in pgoutput.c.