On 3/21/22 12:55, Amit Kapila wrote: > On Sat, Mar 19, 2022 at 3:56 AM Tomas Vondra > <tomas.von...@enterprisedb.com> wrote: >> >> ... >> >> However, while looking at how pgoutput, I realized one thing - for row >> filters we track them "per operation", depending on which operations are >> defined for a given publication. Shouldn't we do the same thing for >> column lists, really? >> >> I mean, if there are two publications with different column lists, one >> for inserts and the other one for updates, isn't it wrong to merge these >> two column lists? >> > > The reason we can't combine row filters for inserts with > updates/deletes is that if inserts have some column that is not > present in RI then during update filtering (for old tuple) it will > give an error as the column won't be present in WAL log. > > OTOH, the same problem won't be there for the column list/filter patch > because all the RI columns are there in the column list (for > update/delete) and we don't need to apply a column filter for old > tuples in either update or delete. > > Basically, the filter rules are slightly different for row filters and > column lists, so we need them (combine of filters) for one but not for > the other. Now, for the sake of consistency with row filters, we can > do it but as such there won't be any problem or maybe we can just add > a comment for the same in code. >
OK, thanks for the explanation. I'll add a comment explaining this to the function initializing the column filter. regards -- Tomas Vondra EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
