MIME-Version: 1.0
References: <149ff9264db27cdf724b65709fbbaee4bf316835.camel@j-davis.com>
 <CAExHW5vv-78ixJs3arsuZ+12A4AyqehJnDPhejp0m4FAKG6JZA@mail.gmail.com>
 <830a2bc6cbbb2e6e01c6c0d9f31f320822e10603.camel@j-davis.com>
 <CAExHW5sAo4Gv3AwuxQNGSQ2Z45B8_MZEb-SG-B8D-hLMdrquAg@mail.gmail.com>
 <e531ec798298a21d671babd45849092850b8675e.camel@j-davis.com>
 <ac4042d6-204c-9661-9949-79ab8a1f8604@joeconway.com>
 <CAExHW5unvpDv6yMSmqurHP7Du1PqoJFWVxeK-4YNm5EnoNJiSQ@mail.gmail.com>
 <433d0845248e86c0317d9d396926182cfe157340.camel@j-davis.com>
 <CAExHW5sQVJeCgCGMkum_k4Z4VPaK5GkdAjHW-d+F3MngBZ9qBA@mail.gmail.com>
 <05ae37abb207cd6bf6b126780024692d91402b0b.camel@j-davis.com>
 <93392ffa941ab0d436e19e0ab5d04d0e42c02d3f.camel@j-davis.com>
 <26be917cb07b6aa3ef5dd15f6b59d1b375ece6e8.camel@j-davis.com>
 <CALj2ACXDua2Az15Kj3OZFaRm49G8-faemiEEv8t9GNCcsxv8Hw@mail.gmail.com>
 <55201bd916e748acfc754c8f95880dae8e4e5ed0.camel@j-davis.com>
 <CAExHW5v5poohyfNRVQp3yjVE56ej0dWvVMbysSSVtg21aHT3uQ@mail.gmail.com>
 <e71e029309171eb8b6ca393306f9bc5acfbfdf8f.camel@j-davis.com>
 <CAExHW5vF+cp9efQj=-W+Rhbr9f9ZZqt3XFnP0NB5jKsm=C=5tw@mail.gmail.com>
 <2a89b14a2b1622bffb8b137ca1f9ab7866f2d2b9.camel@j-davis.com>
 <61831790a0a937038f78ce09f8dd4cef7de7456a.camel@j-davis.com>
 <CAExHW5uCzS-VeSYQHTHxFSdQik-f_O892xmzrzm2fuO+ro+otA@mail.gmail.com>
 <0910b47040406c1d24ec0150dafb5bae6b910ed7.camel@j-davis.com>
 <CAExHW5vDPBB_PShBmSj=v=Jf1K=vSmWdPZTzCJsLpqDgqek+sA@mail.gmail.com>
 <7338f22c4534322a08ab6ce9f879e2e308eb5e5d.camel@j-davis.com>
 <CAExHW5uirmv8tj7LJ3zDo2tfaP_fffAeRbKT--3vBe7pa0in0g@mail.gmail.com>
 <d233117a82774de6e606cb383d1e0efea72c8879.camel@j-davis.com>
 <CAExHW5v5yn7HSD86OJ+Fj-FUcZK4mT40i7DBZoU2hQwfpeYLvw@mail.gmail.com>
 <e0914faf80f4f7f099f6f33597dd3b0f75779cec.camel@j-davis.com>
 <34fd5885b8245d1014f4426ea22af61229d42e3e.camel@j-davis.com>
 <e37776aa4d5679e2efc7d81e7dae4a8998658e37.camel@j-davis.com>
 <e0c6fd0fa6036df36779c8bd8ae763c6f4064135.camel@j-davis.com>
 <CANhcyEUoJeXw2W8TtUZRK48YLuV7R_cKsu=KfvgCAh0YqCC4gw@mail.gmail.com>
 <7a5df376fffb273430aec9e89f88c31d52dcf295.camel@j-davis.com>
 <5dfe845221db2e7d38fc7c2a18a4ba5ea29cdfc0.camel@j-davis.com>
 <CAD21AoA3dOqh4DeRtLJjzBxYaMfmzxw+s9tMo_wgnV7RdfUvtA@mail.gmail.com>
 <60ff024706fe1beab62a89ac07eb6a721856de2e.camel@j-davis.com>
 <b881ea575dab426422e483ab7edfcd98b532cbef.camel@j-davis.com>
 <CAA4eK1K79RCQ-WrN3gvdC=HzRcpeOhho+kWWKWatKzm4v_aypg@mail.gmail.com>
 <80303af653a3da2a94e32ff91d6538675e921bf0.camel@j-davis.com>
In-Reply-To: <80303af653a3da2a94e32ff91d6538675e921bf0.camel@j-davis.com>
From: Amit Kapila <amit.kapila16@gmail.com>
Date: Sat, 7 Mar 2026 12:31:35 +0530
Message-ID: 
 <CAA4eK1LyHvRoNzZPpPQqo7a=5Wov8F-7+KDduy-9ymcRm=Batg@mail.gmail.com>
Subject: Re: [19] CREATE SUBSCRIPTION ... SERVER
To: Jeff Davis <pgsql@j-davis.com>
Cc: Masahiko Sawada <sawada.mshk@gmail.com>,
 Shlok Kyal <shlok.kyal.oss@gmail.com>,
	Ashutosh Bapat <ashutosh.bapat.oss@gmail.com>,
	Bharath Rupireddy <bharath.rupireddyforpostgres@gmail.com>,
 Joe Conway <mail@joeconway.com>,
	pgsql-hackers@postgresql.org
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: 
 <https://www.postgresql.org/message-id/CAA4eK1LyHvRoNzZPpPQqo7a%3D5Wov8F-7%2BKDduy-9ymcRm%3DBatg%40mail.gmail.com>
Precedence: bulk

On Thu, Mar 5, 2026 at 2:23=E2=80=AFPM Jeff Davis <pgsql@j-davis.com> wrote=
:
>
> Additionally, I ran into a problem that's worth highlighting:
>
> DROP SERVER ... CASCADE was broken, because the subscription is
> dependent on it but that's in a global catalog, which is not handled by
> doDeletion(). The subscription is conceptually a per-database object,
> but it's in a shared catalog with a subdbid field. I solved that
> problem by adding a guard to findDependentObjects() to check for the
> referenced object belonging to a shared catalog, and if so it just
> throws an error (so CASCADE is not supported for servers used in
> subscriptions). That's a simple but not a very satisfying solution, so
> let me know if you see a problem with that.
>

I also can't think of any straight-forward solution for it. I've not
thought in detail but can a new type of dependency be required to
solve this problem? I am not aware if we are doing something similar
in any other CASCADE operation, so even if we want to go with giving
ERROR for this case, it may be better to get somewhat wider acceptance
for the same unless few other people respond here and consider this as
an acceptable solution.

Few other minor comments:
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
1.
+# Replicate the changes without columns
+$node_publisher->safe_psql('postgres', "CREATE TABLE tab_no_col()");
+$node_publisher->safe_psql('postgres',
+ "INSERT INTO tab_no_col default VALUES");

I don't see a subscriber-side table or verification code to verify the
above test.

2.
+ Oid subserver BKI_LOOKUP_OPT(pg_foreign_server); /* If connection uses
+ * server */
+

Isn't it better to keep this along with other oids in the beginning of
the catalog, say after subowner? It will also avoid padding before
subserver field.

--=20
With Regards,
Amit Kapila.