Re: Pgoutput not capturing the generated columns - Mailing list pgsql-hackers

From vignesh C
Subject Re: Pgoutput not capturing the generated columns
Date
Msg-id CALDaNm3Pu0eSmO47sjb32oArpFhyvobGEaTDaOe9hbh17n6N_g@mail.gmail.com
Whole thread Raw
In response to Re: Pgoutput not capturing the generated columns  (Peter Smith <smithpb2250@gmail.com>)
List 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



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: pg_dumpall appendPQExpBuffer construct sql need an white space
Next
From: Tom Lane
Date:
Subject: Re: TOAST versus toast