On 2022-Apr-27, Amit Kapila wrote: > On Tue, Apr 26, 2022 at 4:00 AM Tomas Vondra > <tomas.von...@enterprisedb.com> wrote:
> > I can take a stab at it, but it seems strange to not apply the same > > logic to evaluation of publish_as_relid. > > Yeah, the current behavior seems to be consistent with what we already > do. Sorry, this argument makes no sense to me. The combination of both features is not consistent, and both features are new. 'publish_as_relid' is an implementation detail. If the implementation fails to follow the feature design, then the implementation must be fixed ... not the design! IMO, we should first determine how we want row filters and column lists to work when used in conjunction -- for relations (sets of rows) in a general sense. After we have done that, then we can use that design to drive how we want partitioned tables to be handled for it. Keep in mind that when users see a partitioned table, what they first see is a table. They want all their tables to work in pretty much the same way -- partitioned or not partitioned. The fact that a table is partitioned should affect as little as possible the way it interacts with other features. Now, another possibility is to say "naah, this is too hard", or even "naah, there's no time to write all that for this release". That might be okay, but in that case let's add an implementation restriction to ensure that we don't paint ourselves in a corner regarding what is reasonable behavior. For example, an easy restriction might be: if a table is in multiple publications with mismatching row filters/column lists, then a subscriber is not allowed to subscribe to both publications. (Maybe this restriction isn't exactly what we need so that it actually implements what we need, not sure). Then, if/when in the future we implement this correctly, we can lift the restriction. -- Álvaro Herrera 48°01'N 7°57'E — https://www.EnterpriseDB.com/ "La conclusión que podemos sacar de esos estudios es que no podemos sacar ninguna conclusión de ellos" (Tanenbaum)