On Thu, Jan 6, 2022 at 6:42 PM Euler Taveira <eu...@eulerto.com> wrote: > > On Thu, Jan 6, 2022, at 1:18 AM, Amit Kapila wrote: > > On Thu, Jan 6, 2022 at 8:43 AM Peter Smith <smithpb2...@gmail.com> wrote: > > > > On Wed, Jan 5, 2022 at 9:52 PM Amit Kapila <amit.kapil...@gmail.com> wrote: > > > > > ... > > > > > Another minor comment: > > > +static bool pgoutput_row_filter(enum ReorderBufferChangeType changetype, > > > > > > Do we need to specify the 'enum' type before changetype parameter? > > > > > > > That is because there is currently no typedef for the enum > > ReorderBufferChangeType. > > > > But I see that the 0002 patch is already adding the required typedef. > > 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. -- With Regards, Amit Kapila.
