MIME-Version: 1.0
References: 
 <CAKz==b+k7OwOib__LgfDadUzW9jFrbQ9FqdERpsufi8d7F=vkQ@mail.gmail.com>
In-Reply-To: 
 <CAKz==b+k7OwOib__LgfDadUzW9jFrbQ9FqdERpsufi8d7F=vkQ@mail.gmail.com>
From: Amit Kapila <amit.kapila16@gmail.com>
Date: Mon, 30 Mar 2026 12:50:47 +0530
Message-ID: 
 <CAA4eK1KwFKFYnXqYm22oMdQCpLxaLp4ch=YBVUkvGmiA=AUXjA@mail.gmail.com>
Subject: Re: pg_publication_tables: return NULL attnames when no column list
 is specified
To: Roberto Mello <roberto.mello@gmail.com>
Cc: PostgreSQL Developers <pgsql-hackers@lists.postgresql.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: 
 <https://www.postgresql.org/message-id/CAA4eK1KwFKFYnXqYm22oMdQCpLxaLp4ch%3DYBVUkvGmiA%3DAUXjA%40mail.gmail.com>
Precedence: bulk

On Thu, Mar 26, 2026 at 1:21=E2=80=AFAM Roberto Mello <roberto.mello@gmail.=
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 prob=
lem
> where a table in two publications (one with a column list naming all colu=
mns,
> 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 w=
as
> to synthesize a column list when none was specified, filtering out droppe=
d
> 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 fr=
om
> fd0b9dcebda - which was supposed to reverse the synthesis - was broken fr=
om
> 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 th=
e
> 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.

--=20
With Regards,
Amit Kapila.