On Wed, Sep 11, 2024 at 10:30 PM Peter Smith <smithpb2...@gmail.com> wrote: > > Because this feature is now being implemented as a PUBLICATION option, > there is another scenario that might need consideration; I am thinking > about where the same table is published by multiple PUBLICATIONS (with > different option settings) that are subscribed by a single > SUBSCRIPTION. > > e.g.1 > ----- > CREATE PUBLICATION pub1 FOR TABLE t1 WITH (publish_generated_columns = true); > CREATE PUBLICATION pub2 FOR TABLE t1 WITH (publish_generated_columns = false); > CREATE SUBSCRIPTION sub ... PUBLICATIONS pub1,pub2; > ----- > > e.g.2 > ----- > CREATE PUBLICATION pub1 FOR ALL TABLES WITH (publish_generated_columns = > true); > CREATE PUBLICATION pub2 FOR TABLE t1 WITH (publish_generated_columns = false); > CREATE SUBSCRIPTION sub ... PUBLICATIONS pub1,pub2; > ----- > > Do you know if this case is supported? If yes, then which publication > option value wins?
I would expect these option values are processed with OR. That is, we publish changes of the generated columns if at least one publication sets publish_generated_columns to true. It seems to me that we treat multiple row filters in the same way. > > The CREATE SUBSCRIPTION docs [1] only says "Subscriptions having > several publications in which the same table has been published with > different column lists are not supported." > > Perhaps the user is supposed to deduce that the example above would > work OK if table 't1' has no generated cols. OTOH, if it did have > generated cols then the PUBLICATION column lists must be different and > therefore it is "not supported" (??). With the patch, how should this feature work when users specify a generated column to the column list and set publish_generated_column = false, in the first place? raise an error (as we do today)? or always send NULL? Regards, -- Masahiko Sawada Amazon Web Services: https://aws.amazon.com
