From: | Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org> |
---|---|
To: | Rahila Syed <rahilasyed90(at)gmail(dot)com> |
Cc: | Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>, Tomas Vondra <tomas(dot)vondra(at)enterprisedb(dot)com>, Peter Smith <smithpb2250(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Column Filtering in Logical Replication |
Date: | 2021-12-17 15:58:50 |
Message-ID: | 202112171558.klt66al2w5yg@alvherre.pgsql |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 2021-Dec-17, Rahila Syed wrote:
> > This means that we need to support changing the column list of a
> > table in a publication. I'm looking at implementing some form of
> > ALTER PUBLICATION for that.
>
> I think right now the patch contains support only for ALTER
> PUBLICATION.. ADD TABLE with column filters. In order to achieve
> changing the column lists of a published table, I think we can extend
> the ALTER TABLE ..SET TABLE syntax to support specification of column
> list.
Yeah, that's what I was thinking too.
> > So this whole thing can be reduced to just this:
>
> > if (att_map != NULL && !bms_is_member(att->attnum, att_map))
> > continue; /* that is, don't send this attribute */
>
> I agree the condition can be shortened now. The long if condition was
> included because initially the feature allowed specifying filters
> without replica identity columns(sent those columns internally without
> user having to specify).
Ah, true, I had forgotten that. Thanks.
> > 900 + * the table is partitioned. Run a recursive query to iterate through all
> > 901 + * the parents of the partition and retreive the record for the parent
> > 902 + * that exists in pg_publication_rel.
> > 903 + */
>
> The above comment in fetch_remote_table_info() can be changed as the
> recursive query is no longer used.
Oh, of course.
I'll finish some loose ends and submit a v10, but it's still not final.
--
Álvaro Herrera 39°49'30"S 73°17'W — https://www.EnterpriseDB.com/
"Right now the sectors on the hard disk run clockwise, but I heard a rumor that
you can squeeze 0.2% more throughput by running them counterclockwise.
It's worth the effort. Recommended." (Gerry Pourwelle)
From | Date | Subject | |
---|---|---|---|
Next Message | Justin Pryzby | 2021-12-17 17:21:13 | Re: pg_upgrade should truncate/remove its logs before running |
Previous Message | Justin Pryzby | 2021-12-17 15:43:56 | \d with triggers: more than one row returned by a subquery used as an expression |