On Mon, Aug 17, 2026, at 9:00 PM, Bharath Rupireddy wrote:
>
> Please have a look at the v5 patch.
>
I took another look at it.
+-- 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.
+CREATE TABLE gtest1 (
+ a int PRIMARY KEY,
+ b int,
+ c int GENERATED ALWAYS AS (a + b) VIRTUAL,
+ d int GENERATED ALWAYS AS (a * 2) STORED,
+ e int
+);
+INSERT INTO gtest1 (a, b) VALUES (1, 10), (2, 20);
+UPDATE gtest1 SET b = 99 WHERE a = 1;
+DELETE FROM gtest1 WHERE a = 2;
+SELECT data FROM pg_logical_slot_get_changes('regression_slot', NULL, NULL,
'include-xids', '0', 'skip-empty-xacts', '1');
+DROP TABLE gtest1;
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.
-- check generated columns
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.
+ /*
+ * 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.
--
Euler Taveira
EDB https://www.enterprisedb.com/
