On Fri, Jan 7, 2022, at 3:35 AM, Amit Kapila wrote: > On Fri, Jan 7, 2022 at 9:44 AM Amit Kapila <amit.kapil...@gmail.com> wrote: > > > > On Thu, Jan 6, 2022 at 6:42 PM Euler Taveira <eu...@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. WFM. I used numbers + comments in a previous patch set [1]. I suggested the enum because each command would be self explanatory.
[1] https://www.postgresql.org/message-id/49ba49f1-8bdb-40b7-ae9e-f17d88b3afcd%40www.fastmail.com -- Euler Taveira EDB https://www.enterprisedb.com/
