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> <63ceeec59ad6c07e17ce280e4bae31b65806ec06.camel@j-davis.com>
 <CA+TgmoZ9OB7tGt+1LST=Mv_qC_LOnaqkd1D9FmkrBG1He3JJgg@mail.gmail.com>
In-Reply-To: <CA+TgmoZ9OB7tGt+1LST=Mv_qC_LOnaqkd1D9FmkrBG1He3JJgg@mail.gmail.com>
From: Ashutosh Bapat <ashutosh.bapat.oss@gmail.com>
Date: Mon, 4 Sep 2023 18:04:28 +0530
Message-ID: <CAExHW5vf4bg=LGM6HWmmzXEiLEtd2+Q1Ae4aVU6M1Njf7SRYuQ@mail.gmail.com>
Subject: Re: [17] CREATE SUBSCRIPTION ... SERVER
To: Robert Haas <robertmhaas@gmail.com>
Cc: Jeff Davis <pgsql@j-davis.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/CAExHW5vf4bg%3DLGM6HWmmzXEiLEtd2%2BQ1Ae4aVU6M1Njf7SRYuQ%40mail.gmail.com>
Precedence: bulk

On Sat, Sep 2, 2023 at 1:41=E2=80=AFAM Robert Haas <robertmhaas@gmail.com> =
wrote:
>
> On Fri, Sep 1, 2023 at 4:04=E2=80=AFPM Jeff Davis <pgsql@j-davis.com> wro=
te:
> > On Thu, 2023-08-31 at 17:17 -0400, Joe Conway wrote:
> > > Maybe move postgres_fdw to be a first class built in feature instead
> > > of
> > > an extension?
> >
> > That could make sense, but we still have to solve the problem of how to
> > present a built-in FDW.
> >
> > FDWs don't have a schema, so it can't be inside pg_catalog. So we'd
> > need some special logic somewhere to make pg_dump and psql \dew work as
> > expected, and I'm not quite sure what to do there.
>
> I'm worried that an approach based on postgres_fdw would have security
> problems. I think that we don't want postgres_fdw installed in every
> PostgreSQL cluster for security reasons. And I think that the set of
> people who should be permitted to manage connection strings for
> logical replication subscriptions could be different from the set of
> people who are entitled to use postgres_fdw.

If postgres_fdw was the only way to specify a connection to be used
with subscriptions, what you are saying makes sense. But it's not. We
will continue to support current mechanism which doesn't require
postgres_fdw to be installed on every PostgreSQL cluster.

What security problems do you foresee if postgres_fdw is used in
addition to the current mechanism?

--=20
Best Wishes,
Ashutosh Bapat