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>
In-Reply-To: <d233117a82774de6e606cb383d1e0efea72c8879.camel@j-davis.com>
From: Ashutosh Bapat <ashutosh.bapat.oss@gmail.com>
Date: Wed, 31 Jan 2024 11:10:00 +0530
Message-ID: 
 <CAExHW5v5yn7HSD86OJ+Fj-FUcZK4mT40i7DBZoU2hQwfpeYLvw@mail.gmail.com>
Subject: Re: [17] CREATE SUBSCRIPTION ... SERVER
To: Jeff Davis <pgsql@j-davis.com>
Cc: 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/CAExHW5v5yn7HSD86OJ%2BFj-FUcZK4mT40i7DBZoU2hQwfpeYLvw%40mail.gmail.com>
Precedence: bulk

On Wed, Jan 31, 2024 at 2:16=E2=80=AFAM Jeff Davis <pgsql@j-davis.com> wrot=
e:
>
> On Tue, 2024-01-30 at 16:17 +0530, Ashutosh Bapat wrote:
> > Converting a server and user mapping to
> > conninfo should be delegated to the FDW being used since that FDW
> > knows best how to use those options.
>
> If I understand you correctly, you mean that there would be a new
> optional function associated with an FDW (in addition to the HANDLER
> and VALIDATOR) like "CONNECTION", which would be able to return the
> conninfo from a server using that FDW. Is that right?

I am not sure whether it fits {HANDLER,VALIDATOR} set or should be
part of FdwRoutine or a new set of hooks similar to FdwRoutine. But
something like that. Since the hooks for query planning and execution
have different characteristics from the ones used for replication, it
might make sense to create a new set of hooks similar to FdwRoutine,
say FdwReplicationRoutines and rename FdwRoutines to FdwQueryRoutines.
This way, we know whether an FDW can handle subscription connections
or not. A SERVER whose FDW does not support replication routines
should not be used with a subscription.

>
> I like the idea -- it further decouples the logic from the core server.
> I suspect it will make postgres_fdw the primary way (though not the
> only possible way) to use this feature. There would be little need to
> create a new builtin FDW to make this work.

That's what I see as well. I am glad that we are on the same page.

>
> To get the subscription invalidation right, we'd need to make the
> (reasonable) assumption that the connection information is based only
> on the FDW, server, and user mapping. A FDW wouldn't be able to use,
> for example, some kind of configuration table or GUC to control how the
> connection string gets created. That's easy enough to solve with
> documentation.
>

I think that's true for postgres_fdw as well right? But I think it's
more important for a subscription since it's expected to live very
long almost as long as the server itself does. So I agree. But that's
FDW's responsibility.

--=20
Best Wishes,
Ashutosh Bapat