From: | "Euler Taveira" <euler(at)eulerto(dot)com> |
---|---|
To: | pgsql-hackers(at)lists(dot)postgresql(dot)org |
Subject: | Re: Pgoutput not capturing the generated columns |
Date: | 2023-08-01 14:51:45 |
Message-ID: | 283bd642-91f7-4b70-a331-7095e0dae13d@app.fastmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Tue, Aug 1, 2023, at 3:47 AM, Rajendra Kumar Dangwal wrote:
> With decoderbufs and wal2json the connector is able to capture the generated column `full_name` in above example. But with pgoutput the generated column was not captured.
wal2json materializes the generated columns before delivering the output. I
decided to materialized the generated columns in the output plugin because the
target consumers expects a complete row.
> Is this a known limitation of pgoutput plugin? If yes, where can we request to add support for this feature?
I wouldn't say limitation but a design decision.
The logical replication design decides to compute the generated columns at
subscriber side. It was a wise decision aiming optimization (it doesn't
overload the publisher that is *already* in charge of logical decoding).
Should pgoutput provide a complete row? Probably. If it is an option that
defaults to false and doesn't impact performance.
The request for features should be done in this mailing list.
--
Euler Taveira
EDB https://www.enterprisedb.com/
From | Date | Subject | |
---|---|---|---|
Next Message | Tristan Partin | 2023-08-01 15:07:10 | Re: constants for tar header offsets |
Previous Message | Robert Haas | 2023-08-01 14:51:10 | Re: pgsql: Fix search_path to a safe value during maintenance operations. |