Re: Pgoutput not capturing the generated columns
Amit Kapila <amit.kapila16@gmail.com>
On Thu, Nov 7, 2024 at 12:03 PM Peter Eisentraut <peter@eisentraut.org> wrote: > > On 07.11.24 05:13, Amit Kapila wrote: > > On Wed, Nov 6, 2024 at 4:18 PM vignesh C <vignesh21@gmail.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. [1] - https://www.postgresql.org/message-id/CAHv8RjJsGWETA9U53iRiV2%2BVGtnHamEJ5PKMHUcfat269kQaSQ%40mail.gmail.com -- With Regards, Amit Kapila.
Commits
GET /api/v1/messages/:b64id/commits
the thread's linked commits as JSON, with link sources.
API reference →
-
Doc: Generated column replication.
- 6252b1eaf82b 18.0 landed
-
Rename pubgencols_type to pubgencols in pg_publication.
- 75eb9766ec20 18.0 landed
-
Doc: Fix column name in pg_publication catalog.
- 117f9f328e0f 18.0 landed
-
Fix buildfarm failure introduced by commit e65dbc9927.
- b35434b134b1 18.0 landed
-
Change publication's publish_generated_columns option type to enum.
- e65dbc9927fb 18.0 landed
-
Fix \dRp+ output when describing publications with a lower server version.
- 991974bb4888 18.0 landed
-
Replicate generated columns when 'publish_generated_columns' is set.
- 7054186c4ebe 18.0 landed
-
Doc: Update the behavior of generated columns in Logical Replication.
- 5b0c46ea0932 18.0 landed
-
Replicate generated columns when specified in the column list.
- 745217a051a9 18.0 landed
-
Doc: Generated columns are skipped for logical replication.
- 7a089f6e6a14 17.0 cited