Re: Logical Replication Custom Column Expression - Mailing list pgsql-hackers

From Ashutosh Bapat
Subject Re: Logical Replication Custom Column Expression
Date
Msg-id CAExHW5sKO5gHticnCEX-eSemc-btV9tUia-ZBD4DstjiHV+j6g@mail.gmail.com
Whole thread Raw
In response to Re: Logical Replication Custom Column Expression  (Stavros Koureas <koureasstavros@gmail.com>)
List pgsql-hackers
On Wed, Nov 30, 2022 at 2:09 PM Stavros Koureas
<koureasstavros@gmail.com> wrote:
>
>
>
> Στις Τρί 29 Νοε 2022 στις 3:27 μ.μ., ο/η Ashutosh Bapat <ashutosh.bapat.oss@gmail.com> έγραψε:
> > That would be too restrictive - not necessarily in your application
> > but generally. There could be some tables where consolidating rows
> > with same PK from different publishers into a single row in subscriber
> > would be desirable. I think we need to enable the property for every
> > subscriber that intends to add publisher column to the desired and
> > subscribed tables. But there should be another option per table which
> > will indicate that receiver should add publisher when INSERTING row to
> > that table.
>
> So we are discussing the scope level of this property, if this property will be implemented on subscriber level or on
subscribertable. 
> In that case I am not sure how this will be implemented as currently postgres subscribers can have multiple tables
streamedfrom a single publisher. 
> In that case we may have an additional syntax on subscriber, for example:
>
> CREATE SUBSCRIPTION sub1 CONNECTION 'host=localhost port=5432 user=postgres password=XXXXXX dbname=publisher1'
PUBLICATIONpub1 with (enabled = false, create_slot = false, slot_name = NONE, tables = {tableA:union, tableB:none,
....});
>
> Something like this?

Nope, I think we will need to add a table level property through table
options or receiver can infer it by looking at the table columns -
e.g. existence of origin_id column or some such thing.


--
Best Wishes,
Ashutosh Bapat



pgsql-hackers by date:

Previous
From: Amit Langote
Date:
Subject: Re: generic plans and "initial" pruning
Next
From: Bharath Rupireddy
Date:
Subject: WAL Insertion Lock Improvements (was: Re: Avoid LWLockWaitForVar() for currently held WAL insertion lock in WaitXLogInsertionsToFinish())