Re: Column Filtering in Logical Replication

On 2022-Jan-06, Amit Kapila wrote:

> On Mon, Jan 3, 2022 at 8:01 PM Alvaro Herrera <alvherre@alvh.no-ip.org> wrote:
> >
> 
> fetch_remote_table_info()
> {
> ..
> + appendStringInfo(&cmd,
> + "  SELECT pg_catalog.unnest(prattrs)\n"
> + "    FROM pg_catalog.pg_publication p JOIN\n"
> + "         pg_catalog.pg_publication_rel pr ON (p.oid = pr.prpubid)\n"
> + "   WHERE p.pubname IN (%s) AND\n",
> + publications.data);
> + if (!am_partition)
> + appendStringInfo(&cmd, "prrelid = %u", lrel->remoteid);
> + else
> + appendStringInfo(&cmd,
> + "prrelid IN (SELECT relid\n"
> + "    FROM pg_catalog.pg_partition_tree(pg_catalog.pg_partition_root(%u)))",
> + lrel->remoteid);
> 
> IIUC, this doesn't deal with cases when some publication has not
> specified table attrs. In those cases, I think it should return all
> attrs?

Hmm, no, the idea here is that the list of columns should be null; the
code that uses this result is supposed to handle a null result to mean
hat all columns are included.

> Also, it is not very clear to me what exactly we want to do
> with partitions?

... Hmm, maybe there is a gap in testing here, I'll check; but the idea
is that we would use the column list of the most immediate ancestor that
has one, if the partition itself doesn't have one.  (I see we're missing
a check for "pubviaroot", which should represent an override.  Need more
tests here.)

-- 
Álvaro Herrera         PostgreSQL Developer  —  https://www.EnterpriseDB.com/
"Uno puede defenderse de los ataques; contra los elogios se esta indefenso"