Re: Pgoutput not capturing the generated columns

From: Peter Smith <smithpb2250(at)gmail(dot)com>
To: Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>
Cc: Michael Paquier <michael(at)paquier(dot)xyz>, "Shinoda, Noriyoshi (SXD Japan FSIP)" <noriyoshi(dot)shinoda(at)hpe(dot)com>, vignesh C <vignesh21(at)gmail(dot)com>, Shubham Khanna <khannashubham1197(at)gmail(dot)com>, Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com>, Rajendra Kumar Dangwal <dangwalrajendra888(at)gmail(dot)com>, "pgsql-hackers(at)lists(dot)postgresql(dot)org" <pgsql-hackers(at)lists(dot)postgresql(dot)org>, "euler(at)eulerto(dot)com" <euler(at)eulerto(dot)com>
Subject: Re: Pgoutput not capturing the generated columns
Date: 2025-01-15 06:29:41
Message-ID: CAHut+PuQAvGR=D-d=H4kYQ-xnan3oAF8M3m4kqw5vdMjDpnW+g@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Mon, Jan 13, 2025 at 8:27 PM Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> wrote:
>
> On Mon, Jan 13, 2025 at 5:25 AM Peter Smith <smithpb2250(at)gmail(dot)com> wrote:
> >
> > Future -- there probably need to be further clarifications/emphasis to
> > describe how the generated column replication feature only works for
> > STORED generated columns (not VIRTUAL ones), but IMO it is better to
> > address that separately *after* dealing with these missing
> > documentation patches.
> >
>
> I thought it was better to deal with the ambiguity related to the
> 'virtual' part first. I have summarized the options we have regarding
> this in an email [1]. I prefer to extend the current option to take
> values as 's', and 'n'. This will keep the room open to extending it
> with a new value 'v'. The primary reason to go this way is to avoid
> adding new options in the future. It is better to keep the number of
> subscription options under control. Do you have any preference?
>

Hi,

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?

======
Kind Regards,
Peter Smith.
Fujitsu Australia

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Shubham Khanna 2025-01-15 06:33:25 Re: Adding a '--two-phase' option to 'pg_createsubscriber' utility.
Previous Message Michael Paquier 2025-01-15 06:11:32 Re: per backend WAL statistics