Re: Pgoutput not capturing the generated columns

vignesh C <vignesh21@gmail.com>

From: vignesh C <vignesh21@gmail.com>
To: Peter Smith <smithpb2250@gmail.com>
Cc: Amit Kapila <amit.kapila16@gmail.com>, Michael Paquier <michael@paquier.xyz>, "Shinoda, Noriyoshi (SXD Japan FSIP)" <noriyoshi.shinoda@hpe.com>, Shubham Khanna <khannashubham1197@gmail.com>, Masahiko Sawada <sawada.mshk@gmail.com>, Rajendra Kumar Dangwal <dangwalrajendra888@gmail.com>, "pgsql-hackers@lists.postgresql.org" <pgsql-hackers@lists.postgresql.org>, "euler@eulerto.com" <euler@eulerto.com>
Date: 2025-01-16T04:16:34Z
Lists: pgsql-hackers
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

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →
  1. Doc: Generated column replication.

  2. Rename pubgencols_type to pubgencols in pg_publication.

  3. Doc: Fix column name in pg_publication catalog.

  4. Fix buildfarm failure introduced by commit e65dbc9927.

  5. Change publication's publish_generated_columns option type to enum.

  6. Fix \dRp+ output when describing publications with a lower server version.

  7. Replicate generated columns when 'publish_generated_columns' is set.

  8. Doc: Update the behavior of generated columns in Logical Replication.

  9. Replicate generated columns when specified in the column list.

  10. Doc: Generated columns are skipped for logical replication.