On Wed, 15 Jan 2025 at 12:00, Peter Smith <smithpb2...@gmail.com> wrote: > > During my review of Vignesh's patch for the enum-version of > publish_generated_columns, I was thinking of yet another way to > specify which columns to replicate. > > My idea below is analogous to the existing 'publish' option; Instead > of adding an option specific to generated column types why don't we > instead add a (string) option for controlling the publication of *all* > column types? > > Synopsis: > > publish_column_types = <col_types>[,...] > where <col_types> are 'normal', 'generated_stored', 'generated_virtual'. > > The default value is 'normal', which just means everything that's not > generated > > ~ > > This option would be overriding if a publication column list is > specified, same as the current implementation does. > > ~ > > And, just like the 'publish' option the effect is cumulative: > > e.g.1. WITH (publish_column_types = 'normal') == default behavior. > publishes all normal columns same as PG17 > e.g.2. WITH (publish_column_types = 'normal, generated_stored') == > publishes all normal cols AND stored gencols > e.g.3. WITH (publish_column_types = 'generated_stored') == publishes > only the stored gencols and nothing else > > Notice that some combinations (like example 3 above with a FOR ALL > TABLES) are not even possible using master, or Vignesh's patch. Maybe > having this extra flexibility is useful for someone? > > ~ > > Also, having a generic name 'publish_column_types' leaves this open to > be extended with more possible values in the future without > proliferating more publication options. > > Thoughts?
I believe the existing enum is adequate for handling generated columns. Ideally, users would prefer to either have only non-generated columns or all columns in the table. However, since the implementation of virtual generated columns will be phased—starting with the virtual columns and followed by their replication in future updates—an enum is necessary. This will allow users to choose between publish_generated_columns set to none or publish_generated_columns set to stored for now, and later switch to publish_generated_columns set to all once the implementation is complete. Additionally, users who want to select only generated columns can use column list publication. Given these considerations, I believe the current approach is appropriate. Regards, Vignesh
