public inbox for [email protected]
help / color / mirror / Atom feedFrom: David G. Johnston <[email protected]>
To: Álvaro Herrera <[email protected]>
Cc: Roberto Mello <[email protected]>
Cc: PostgreSQL Developers <[email protected]>
Subject: Re: pg_publication_tables: return NULL attnames when no column list is specified
Date: Tue, 31 Mar 2026 15:55:48 -0700
Message-ID: <CAKFQuwa8i+TFSfs_LVCVZpK2jXyjkD_giKPg1rt57AsXrgW=BA@mail.gmail.com> (raw)
In-Reply-To: <[email protected]>
References: <CAKz==b+k7OwOib__LgfDadUzW9jFrbQ9FqdERpsufi8d7F=vkQ@mail.gmail.com>
<[email protected]>
On Thursday, March 26, 2026, Álvaro Herrera <[email protected]> wrote:
> On 2026-Mar-25, Roberto Mello wrote:
>
> > The problem is that pg_get_publication_tables() in pg_publication.c
> > (the set-returning function backing the pg_publication_tables view)
> > erases this distinction. When prattrs is NULL, it opens the table,
> > iterates all eligible attributes, and builds a synthetic int2vector of
> > all current columns. The view then shows the same attnames output for
> > both cases.
>
> I agree that this is wrong. This distinction was explicitly discussed
> when the column-list feature was developed. I don't think we can
> backpatch the fix though, out of fear that we would break something for
> existing users; but we should definitely fix it for pg19.
>
IIUC the wording for v18 and earlier should read more like:
“Subscriptions having several publications in which the same table has
different sets of columns published are not supported.”
The claim that this defacto behavior is a bug needing to be fixed is now
before us (there is no disagreement that the physical column lists are
different - null vs non-null). My cursory take at this leads me to believe
we should accept what actually got implemented and not call this a bug to
be fixed (aside from the docs).
That the catalog is the only official source of truth regarding the
physical column list distinction, and the function represents the logical
“set of columns actually seen”, makes sense seen in that light.
I haven’t dived deep enough to understand whether there is C code issue
that needs to be resolved. Or whether we can make dealing with this more
user-friendly given this constraint.
Removing the limitation would seem more appealing if we are going to make a
change. The obvious answer of “union all sets of columns published for a
table and replicate those” would be the simplest to document though I
suspect the current implementation basically chooses one of the
publications to pull from which makes that difficult in the general case.
I do kinda wonder why we need to enforce any kind of error so long as one
of the publications for a given table includes all columns though. Or even
is a proper superset to be a tiny bit more flexible. A technically
uninformed wondering but still.
David J.
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], [email protected]
Subject: Re: pg_publication_tables: return NULL attnames when no column list is specified
In-Reply-To: <CAKFQuwa8i+TFSfs_LVCVZpK2jXyjkD_giKPg1rt57AsXrgW=BA@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