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

From Amit Kapila
Subject Re: Pgoutput not capturing the generated columns
Date
Msg-id CAA4eK1+bgQX=Q=rO2UEvta0-2p9x74kVXQo3TpR++nq-Ve=LMg@mail.gmail.com
Whole thread Raw
In response to Pgoutput not capturing the generated columns  (Rajendra Kumar Dangwal <dangwalrajendra888@gmail.com>)
Responses Re: Pgoutput not capturing the generated columns
List pgsql-hackers
On Wed, Oct 30, 2024 at 9:46 PM vignesh C <vignesh21@gmail.com> wrote:
>
...
+ /*
+ * For non-column list publications—such as TABLE (without a column
+ * list), ALL TABLES, or ALL TABLES IN SCHEMA publications consider
+ * all columns of the table, including generated columns, based on the
+ * pubgencols option.
+ */
+ if (!cols)
+ {
+ Assert(pub->pubgencols == entry->pubgencols);
+
+ /*
+ * Retrieve the columns if they haven't been prepared yet, or if
+ * there are multiple publications.
+ */
+ if (!relcols && (list_length(publications) > 1))
+ {
+ pgoutput_ensure_entry_cxt(data, entry);
+ relcols = pub_getallcol_bitmapset(relation, entry->pubgencols,
+   entry->entry_cxt);
+ }
+
+ cols = relcols;

Don't we need this only when generated column(s) are present, if so,
we can get that as an input to pgoutput_column_list_init()? We have
already computed that in the function check_and_init_gencol() which is
invoked just before pgoutput_column_list_init().

--
With Regards,
Amit Kapila.



pgsql-hackers by date:

Previous
From: Aleksander Alekseev
Date:
Subject: Re: [PATCH] Rename trim_array() for consistency with the rest of array_* functions
Next
From: Dean Rasheed
Date:
Subject: Re: psql: Add leakproof field to \dAo+ meta-command results