Re: [Patch] Omit virtual generated columns from test_decoding output

Hi,

On Tue, Aug 18, 2026 at 5:52 AM Euler Taveira <euler(at)eulerto(dot)com> wrote:
>
> I took another look at it.

Thanks for reviewing.

> +-- Virtual generated columns are always stored as null in the tuple, so they
> +-- are not printed at all; a printed null would not be distinguishable from a
> +-- column that really contains a null. Stored generated columns are printed
> +-- as usual.
>
> It seems repetitive to say the same explanation in the commit message
> and at the top of this test. It is sufficient to follow the same pattern
> from the tests in this file.

Yes, reworded it to just this: -- check that virtual generated columns
are not printed

> Do you really need to test the 3 commands (I, U, D) here? I'm asking
> because all of them use the same function (tuple_to_stringinfo) behind
> the scenes. If so, I suggest that you use a single transaction instead
> of 3 separate transactions.

Sounds good. I'm all in favor of having fewer in tests, so trimmed it
down to just inserting 1 row.

> + /*
> + * Virtual generated columns are always stored as null in the tuple,
> + * so don't print them at all; a printed null would not be
> + * distinguishable from a column that really contains a null. pgoutput
> + * likewise never publishes virtual generated columns (see
> + * logicalrep_should_publish_column()). Stored generated columns are
> + * printed as usual since their values are actually on disk.
> + */
>
> No need to mention the pgoutput here. It is sufficient (for historical
> reason) that the commit message says it.

Agreed.

Please find the attached v6 patch.

--
Bharath Rupireddy
Amazon Web Services: https://aws.amazon.com