Re: Pgoutput not capturing the generated columns
vignesh C <vignesh21@gmail.com>
On Wed, 15 Jan 2025 at 12:00, Peter Smith <smithpb2250@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
Commits
GET /api/v1/messages/:b64id/commits
the thread's linked commits as JSON, with link sources.
API reference →
-
Doc: Generated column replication.
- 6252b1eaf82b 18.0 landed
-
Rename pubgencols_type to pubgencols in pg_publication.
- 75eb9766ec20 18.0 landed
-
Doc: Fix column name in pg_publication catalog.
- 117f9f328e0f 18.0 landed
-
Fix buildfarm failure introduced by commit e65dbc9927.
- b35434b134b1 18.0 landed
-
Change publication's publish_generated_columns option type to enum.
- e65dbc9927fb 18.0 landed
-
Fix \dRp+ output when describing publications with a lower server version.
- 991974bb4888 18.0 landed
-
Replicate generated columns when 'publish_generated_columns' is set.
- 7054186c4ebe 18.0 landed
-
Doc: Update the behavior of generated columns in Logical Replication.
- 5b0c46ea0932 18.0 landed
-
Replicate generated columns when specified in the column list.
- 745217a051a9 18.0 landed
-
Doc: Generated columns are skipped for logical replication.
- 7a089f6e6a14 17.0 cited