Re: Pgoutput not capturing the generated columns - Mailing list pgsql-hackers
From | Peter Smith |
---|---|
Subject | Re: Pgoutput not capturing the generated columns |
Date | |
Msg-id | CAHut+Pvh9hw3LJK5fU9p7jFBMAr2OjVJWR9GhGj=fgxPSmnsKw@mail.gmail.com Whole thread Raw |
In response to | Re: Pgoutput not capturing the generated columns (Masahiko Sawada <sawada.mshk@gmail.com>) |
Responses |
Re: Pgoutput not capturing the generated columns
Re: Pgoutput not capturing the generated columns |
List | pgsql-hackers |
On Fri, Sep 20, 2024 at 3:26 AM Masahiko Sawada <sawada.mshk@gmail.com> wrote: > > On Thu, Sep 19, 2024 at 2:32 AM Amit Kapila <amit.kapila16@gmail.com> wrote: > > ... > > I think that the column list should take priority and we should > > publish the generated column if it is mentioned in irrespective of > > the option. > > Agreed. > > > ... > > > > Users can use a publication like "create publication pub1 for table > > t1(c1, c2), t2;" where they want t1's generated column to be published > > but not for t2. They can specify the generated column name in the > > column list of t1 in that case even though the rest of the tables > > won't publish generated columns. > > Agreed. > > I think that users can use the publish_generated_column option when > they want to publish all generated columns, instead of specifying all > the columns in the column list. It's another advantage of this option > that it will also include the future generated columns. > OK. Let me give some examples below to help understand this idea. Please correct me if these are incorrect. ====== Assuming these tables: t1(a,b,gen1,gen2) t2(c,d,gen1,gen2) Examples, when publish_generated_columns=false: CREATE PUBLICATION pub1 FOR t1(a,b,gen2), t2 WITH (publish_generated_columns=false) t1 -> publishes a, b, gen2 (e.g. what column list says) t2 -> publishes c, d CREATE PUBLICATION pub1 FOR t1, t2(gen1) WITH (publish_generated_columns=false) t1 -> publishes a, b t2 -> publishes gen1 (e.g. what column list says) CREATE PUBLICATION pub1 FOR t1, t2 WITH (publish_generated_columns=false) t1 -> publishes a, b t2 -> publishes c, d CREATE PUBLICATION pub1 FOR ALL TABLES WITH (publish_generated_columns=false) t1 -> publishes a, b t2 -> publishes c, d ~~ Examples, when publish_generated_columns=true: CREATE PUBLICATION pub1 FOR t1(a,b,gen2), t2 WITH (publish_generated_columns=true) t1 -> publishes a, b, gen2 (e.g. what column list says) t2 -> publishes c, d + ALSO gen1, gen2 CREATE PUBLICATION pub1 FOR t1, t2(gen1) WITH (publish_generated_columns=true) t1 -> publishes a, b + ALSO gen1, gen2 t2 -> publishes gen1 (e.g. what column list says) CREATE PUBLICATION pub1 FOR t1, t2 WITH (publish_generated_columns=true) t1 -> publishes a, b + ALSO gen1, gen2 t2 -> publishes c, d + ALSO gen1, gen2 CREATE PUBLICATION pub1 FOR ALL TABLES WITH (publish_generated_columns=true) t1 -> publishes a, b + ALSO gen1, gen2 t2 -> publishes c, d + ALSO gen1, gen2 ====== The idea LGTM, although now the parameter name ('publish_generated_columns') seems a bit misleading since sometimes generated columns get published "irrespective of the option". So, I think the original parameter name 'include_generated_columns' might be better here because IMO "include" seems more like "add them if they are not already specified", which is exactly what this idea is doing. Thoughts? ====== Kind Regards, Peter Smith. Fujitsu Australia
pgsql-hackers by date: