RE: row filtering for logical replication

On Wed, Jan 12, 2022 5:38 PM Amit Kapila <amit.kapila16@gmail.com> wrote:
> On Wed, Jan 12, 2022 at 3:00 AM Alvaro Herrera <alvherre@alvh.no-ip.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