Re: Virtual generated columns

From: Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>
To: Peter Eisentraut <peter(at)eisentraut(dot)org>
Cc: pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>, jian he <jian(dot)universality(at)gmail(dot)com>, Dean Rasheed <dean(dot)a(dot)rasheed(at)gmail(dot)com>
Subject: Re: Virtual generated columns
Date: 2024-11-10 03:16:37
Message-ID: CAA4eK1LE3=g-u7j1rxcDQUygyFN+_zjRAL3WGPROpwQD1-nMSg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, Nov 5, 2024 at 9:48 PM Peter Eisentraut <peter(at)eisentraut(dot)org> wrote:
>
> On 30.09.24 04:09, Peter Eisentraut wrote:
> > I'm attaching a consolidated patch here, so we have something up to date
> > on the record. I haven't worked through all the other recent feedback
> > from Jian He yet; I'll do that next.
>
> New patch version. I've gone through the whole thread again and looked
> at all the feedback and various bug reports and test cases and made sure
> they are all addressed in the latest patch version. (I'll send some
> separate messages to respond to some individual messages, but I'm
> keeping the latest patch here.)
>

I have tried to analyze this patch's interaction with logical
replication. The patch allows virtual generated columns in row filters
and column lists. But for the column list, it doesn't seem to be
computing the correct value whereas for the row filter, it is working
due to the following change:

@@ -992,7 +993,7 @@ pgoutput_row_filter_init(PGOutputData *data, List
*publications,
continue;

foreach(lc, rfnodes[idx])
- filters = lappend(filters, stringToNode((char *) lfirst(lc)));
+ filters = lappend(filters,
expand_generated_columns_in_expr(stringToNode((char *) lfirst(lc)),
relation));

The possible idea to replicate virtual generated columns is to compute
the corresponding expression before sending the data to the client. If
we can allow it in the row filter than why not to publish it as well.
To allow updates, we need to ensure that the replica identity should
include all columns referenced by the generated expression. For
example, if the generated column is defined as generated always as (c1
+ c2), the replica identity must include both c1 and c2.

Now, if we can't support the replication of virtual generated columns
due to some reason then we can mention in docs for
publish_generated_columns that it is used only to replicate STORED
generated columns but if we can support it then the
publish_generated_columns can accept string values like 'stored',
'virtual', 'all'.

Thoughts?

--
With Regards,
Amit Kapila.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message jian he 2024-11-10 04:26:21 Re: New "single" COPY format
Previous Message David G. Johnston 2024-11-09 20:52:06 Re: New "single" COPY format