MIME-Version: 1.0
In-Reply-To: <202603261226.uo54xj4rpex2@alvherre.pgsql>
References: 
 <CAKz==b+k7OwOib__LgfDadUzW9jFrbQ9FqdERpsufi8d7F=vkQ@mail.gmail.com>
 <202603261226.uo54xj4rpex2@alvherre.pgsql>
From: "David G. Johnston" <david.g.johnston@gmail.com>
Date: Tue, 31 Mar 2026 15:55:48 -0700
Message-ID: 
 <CAKFQuwa8i+TFSfs_LVCVZpK2jXyjkD_giKPg1rt57AsXrgW=BA@mail.gmail.com>
Subject: Re: pg_publication_tables: return NULL attnames when no column list
 is specified
To: =?UTF-8?Q?=C3=81lvaro_Herrera?= <alvherre@kurilemu.de>
Cc: Roberto Mello <roberto.mello@gmail.com>,
	PostgreSQL Developers <pgsql-hackers@lists.postgresql.org>
Content-Type: multipart/alternative; boundary="0000000000004ed6b8064e59dea7"
Archived-At: 
 <https://www.postgresql.org/message-id/CAKFQuwa8i%2BTFSfs_LVCVZpK2jXyjkD_giKPg1rt57AsXrgW%3DBA%40mail.gmail.com>
Precedence: bulk

--0000000000004ed6b8064e59dea7
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Thursday, March 26, 2026, =C3=81lvaro Herrera <alvherre@kurilemu.de> wro=
te:

> 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:

=E2=80=9CSubscriptions having several publications in which the same table =
has
different sets of columns published are not supported.=E2=80=9D

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
=E2=80=9Cset of columns actually seen=E2=80=9D, makes sense seen in that li=
ght.

I haven=E2=80=99t dived deep enough to understand whether there is C code i=
ssue
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 =E2=80=9Cunion all sets of columns published=
 for a
table and replicate those=E2=80=9D 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.

--0000000000004ed6b8064e59dea7
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Thursday, March 26, 2026, =C3=81lvaro Herrera &lt;<a href=3D"mailto:alvh=
erre@kurilemu.de">alvherre@kurilemu.de</a>&gt; wrote:<br><blockquote class=
=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padd=
ing-left:1ex">On 2026-Mar-25, Roberto Mello wrote:<br>
<br>
&gt; The problem is that pg_get_publication_tables() in pg_publication.c<br=
>
&gt; (the set-returning function backing the pg_publication_tables view)<br=
>
&gt; erases this distinction.=C2=A0 When prattrs is NULL, it opens the tabl=
e,<br>
&gt; iterates all eligible attributes, and builds a synthetic int2vector of=
<br>
&gt; all current columns. The view then shows the same attnames output for<=
br>
&gt; both cases.<br>
<br>
I agree that this is wrong.=C2=A0 This distinction was explicitly discussed=
<br>
when the column-list feature was developed.=C2=A0 I don&#39;t think we can<=
br>
backpatch the fix though, out of fear that we would break something for<br>
existing users; but we should definitely fix it for pg19.<br>
</blockquote><div><br></div><div>IIUC the wording for v18 and earlier shoul=
d read more like:</div><div><br></div><div><span style=3D"font-family:&quot=
;Open Sans&quot;,sans-serif;font-size:14.4px">=E2=80=9CSubscriptions having=
 several publications in which the same table has different sets of columns=
 published are not supported.=E2=80=9D</span><br></div><div><span style=3D"=
font-family:&quot;Open Sans&quot;,sans-serif;font-size:14.4px"><br></span><=
/div><div><font face=3D"Open Sans, sans-serif"><span style=3D"font-size:14.=
4px">The claim that this defacto behavior is a bug needing to be fixed is n=
ow before us (there is no disagreement that the physical column lists are d=
ifferent - null vs non-null).=C2=A0 My cursory take at this leads me to bel=
ieve we should accept what actually got implemented and not call this a bug=
 to be fixed (aside from the docs).</span></font></div><div><font face=3D"O=
pen Sans, sans-serif"><span style=3D"font-size:14.4px"><br></span></font></=
div><div><font face=3D"Open Sans, sans-serif"><span style=3D"font-size:14.4=
px">That the catalog is the only official source of truth regarding the phy=
sical column list distinction, and the function represents the logical =E2=
=80=9Cset of columns actually seen=E2=80=9D, makes sense seen in that light=
.</span></font></div><div><font face=3D"Open Sans, sans-serif"><span style=
=3D"font-size:14.4px"><br></span></font></div><div><font face=3D"Open Sans,=
 sans-serif"><span style=3D"font-size:14.4px">I haven=E2=80=99t dived deep =
enough to understand whether there is C code issue that needs to be resolve=
d.=C2=A0 Or whether we can make dealing with this more user-friendly given =
this constraint.</span></font></div><div><font face=3D"Open Sans, sans-seri=
f"><span style=3D"font-size:14.4px"><br></span></font></div><div><font face=
=3D"Open Sans, sans-serif"><span style=3D"font-size:14.4px">Removing the li=
mitation would seem more appealing if we are going to make a change.=C2=A0 =
The obvious answer of =E2=80=9Cunion all sets of columns published for a ta=
ble and replicate those=E2=80=9D would be the simplest to document though I=
 suspect the current implementation basically chooses one of the publicatio=
ns to pull from which makes that difficult in the general case.=C2=A0 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.=C2=A0 Or even =
is a proper superset to be a tiny bit more flexible.=C2=A0 A technically un=
informed wondering but still.</span></font></div><div><font face=3D"Open Sa=
ns, sans-serif"><span style=3D"font-size:14.4px"><br></span></font></div><d=
iv><font face=3D"Open Sans, sans-serif"><span style=3D"font-size:14.4px">Da=
vid J.</span></font></div><div><font face=3D"Open Sans, sans-serif"><span s=
tyle=3D"font-size:14.4px"><br></span></font></div><div><span style=3D"font-=
family:&quot;Open Sans&quot;,sans-serif;font-size:14.4px"><br></span></div>

--0000000000004ed6b8064e59dea7--