public inbox for [email protected]  

help / color / mirror / Atom feed

From: Amit Kapila <[email protected]>
To: Roberto Mello <[email protected]>
Cc: PostgreSQL Developers <[email protected]>
Subject: Re: pg_publication_tables: return NULL attnames when no column list is specified
Date: Mon, 30 Mar 2026 12:50:47 +0530
Message-ID: <CAA4eK1KwFKFYnXqYm22oMdQCpLxaLp4ch=YBVUkvGmiA=AUXjA@mail.gmail.com> (raw)
In-Reply-To: <CAKz==b+k7OwOib__LgfDadUzW9jFrbQ9FqdERpsufi8d7F=vkQ@mail.gmail.com>
References: <CAKz==b+k7OwOib__LgfDadUzW9jFrbQ9FqdERpsufi8d7F=vkQ@mail.gmail.com>

On Thu, Mar 26, 2026 at 1:21 AM Roberto Mello <[email protected]> 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.

view thread (12+ messages)  latest in thread

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: [email protected]
  Cc: [email protected], [email protected], [email protected]
  Subject: Re: pg_publication_tables: return NULL attnames when no column list is specified
  In-Reply-To: <CAA4eK1KwFKFYnXqYm22oMdQCpLxaLp4ch=YBVUkvGmiA=AUXjA@mail.gmail.com>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox