RE: row filtering for logical replication

On Wed, Jan 12, 2022 5:38 PM Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> wrote:
> On Wed, Jan 12, 2022 at 3:00 AM Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>
> wrote:
> >
> > I just looked at 0002 because of Justin Pryzby's comment in the column
> > filtering thread, and realized that the pgoutput row filtering has a
> > very strange API, which receives both heap tuples and slots; and we
> > seem to convert to and from slots in seemingly unprincipled ways. I
> > don't think this is going to fly. I think it's OK for the initial
> > entry into pgoutput to be HeapTuple (but only because that's what
> > ReorderBufferTupleBuf has), but it should be converted a slot right
> > when it enters pgoutput, and then used as a slot throughout.
> >
>
> One another thing that we can improve about 0002 is to unify the APIs for row
> filtering for update and insert/delete. I find having separate APIs a bit awkward.

Thanks for the comments.

Attach the v63 patch set which include the following changes.

Based on Alvaro and Amit's suggestions:
- merged 0001 and 0002 into one patch.
- did some initial refactorings for the interface of row_filter functions.
For now, it receives only slots.
- unify the APIs for row filtering for update and insert/delete

And addressed some comments received earlier.
- update some comments and some cosmetic changes. (Peter)
- Add a new enum RowFilterPubAction use as the index of filter expression (Euler,Amit)
array.
- Fix a bug that when transform UPDATE to INSERT, the patch didn't pass the (Euler)
transformed tuple to logicalrep_write_insert.

Best regards,
Hou zj