Re: pg_publication_tables: return NULL attnames when no column list is specified

From: Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>
To: Roberto Mello <roberto(dot)mello(at)gmail(dot)com>
Cc: PostgreSQL Developers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: pg_publication_tables: return NULL attnames when no column list is specified
Date: 2026-03-30 07:20:47
Message-ID: CAA4eK1KwFKFYnXqYm22oMdQCpLxaLp4ch=YBVUkvGmiA=AUXjA@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, Mar 26, 2026 at 1:21 AM Roberto Mello <roberto(dot)mello(at)gmail(dot)com> wrote:
>
> 2. b7ae0395369 (01/2023) Amit Kapila (author: Shi yu)
> Ignore dropped and generated columns from the column list
>
> This is the commit that introduced the synthesis loop. It "solved" a problem
> where a table in two publications (one with a column list naming all columns,
> one without a column list) was erroring with "cannot use different column lists"
> because one returned NULL and the other returned an int2vector. The fix was
> to synthesize a column list when none was specified, filtering out dropped
> and generated columns, so that both publications would produce identical
> int2vectors and DISTINCT would collapse them to one row.
>
> But this synthesis made it impossible to distinguish "all columns" from
> "explicit list of all columns" in the view. And the relnatts heuristic from
> fd0b9dcebda - which was supposed to reverse the synthesis - was broken from
> the start because relnatts includes dropped columns while the synthesized list
> excludes them.
>
> The synthesis in b7ae0395369 tried to make "no column list" and "explicit list
> of all columns" look identical. But they have genuinely different
> semantics:
>
> - No column list (NULL): all current and future columns are replicated.
> ALTER TABLE ADD COLUMN automatically replicates the new column.
> - Explicit full list: only the named columns are replicated. New columns
> are NOT replicated until the publication is explicitly altered.
>
> By making them indistinguishable, the synthesis hid a real conflict from users
> who had a table in two publications with different column semantics on the
> same subscription. I am proposing a fix that restores the distinction and correctly
> (IMO) surfaces this conflict.
>

I would like to understand why shall we consider this as a conflict?
IIRC, we tried to ensure that if in future new columns get added to
the relation and the same is not updated in the explicit column list
then it will result in error.

--
With Regards,
Amit Kapila.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Anton A. Melnikov 2026-03-30 07:28:30 .bc files build dependency issues.
Previous Message Zhijie Hou (Fujitsu) 2026-03-30 07:16:43 RE: Initial COPY of Logical Replication is too slow