From: | Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> |
---|---|
To: | Peter Eisentraut <peter(at)eisentraut(dot)org> |
Cc: | vignesh C <vignesh21(at)gmail(dot)com>, Peter Smith <smithpb2250(at)gmail(dot)com>, Shubham Khanna <khannashubham1197(at)gmail(dot)com>, Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com>, Rajendra Kumar Dangwal <dangwalrajendra888(at)gmail(dot)com>, pgsql-hackers(at)lists(dot)postgresql(dot)org, euler(at)eulerto(dot)com |
Subject: | Re: Pgoutput not capturing the generated columns |
Date: | 2024-11-07 09:50:04 |
Message-ID: | CAA4eK1JVzBRKMwkVBCwpZfYr+tRsfvTHPuHiqrSP7XQ1epbjhw@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Thu, Nov 7, 2024 at 12:03 PM Peter Eisentraut <peter(at)eisentraut(dot)org> wrote:
>
> On 07.11.24 05:13, Amit Kapila wrote:
> > On Wed, Nov 6, 2024 at 4:18 PM vignesh C <vignesh21(at)gmail(dot)com> wrote:
> >>
> >> The attached v50 version patch has the changes for the same.
>
> Could you (everybody on this thread) please provide guidance how this
> feature is supposed to interact with virtual generated columns [0]. I
> don't think it's reasonably possible to replicate virtual generated
> columns.
>
I haven't studied the patch but can't we think of a way where we can
compute the value of the virtual generated column on the fly (say by
evaluating the required expression) before sending it to the client?
We do evaluate the expressions during the row filter, so can't we do
it for virtual-generated columns? I think we need some more work
similar to row filter/column list where we need to ensure that the
columns used in expressions for virtual generated columns must be part
of replica identity. I haven't thought about all the details so I may
be missing something.
>
I had previously suggested to make it more explicit that this
> feature only works for stored generated columns (e.g., name the option
> like that), but I don't see that this was considered.
>
It was considered in earlier versions of the patch like [1] but later
we focussed more on getting key parts of the feature ready. Sorry for
missing that part but we can do it now. The idea is that we explicitly
mention in docs that the new option 'publish_generated_columns' will
replicate only STORED generated columns and also explicitly compare
'attgenerated' as ATTRIBUTE_GENERATED_STORED during decoding and
adjust comments. I suggest we do that for now. We could also consider
naming the option as publish_stored_generated_columns but that way the
name would be too long. The other idea could be to make the new option
as a string but that would be useful only if we decide to replicate
virtual generated columns.
--
With Regards,
Amit Kapila.
From | Date | Subject | |
---|---|---|---|
Next Message | Amit Langote | 2024-11-07 09:57:08 | Re: doc fail about ALTER TABLE ATTACH re. NO INHERIT |
Previous Message | Dean Rasheed | 2024-11-07 09:35:42 | Re: Virtual generated columns |