Re: [17] CREATE SUBSCRIPTION ... SERVER

From: Ashutosh Bapat <ashutosh(dot)bapat(dot)oss(at)gmail(dot)com>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Jeff Davis <pgsql(at)j-davis(dot)com>, Joe Conway <mail(at)joeconway(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: [17] CREATE SUBSCRIPTION ... SERVER
Date: 2023-09-04 12:34:28
Message-ID: CAExHW5vf4bg=LGM6HWmmzXEiLEtd2+Q1Ae4aVU6M1Njf7SRYuQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Sat, Sep 2, 2023 at 1:41 AM Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
>
> On Fri, Sep 1, 2023 at 4:04 PM Jeff Davis <pgsql(at)j-davis(dot)com> wrote:
> > 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?

--
Best Wishes,
Ashutosh Bapat

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Aleksander Alekseev 2023-09-04 12:35:12 Re: A minor adjustment to get_cheapest_path_for_pathkeys
Previous Message Peter Eisentraut 2023-09-04 12:32:56 Re: Avoid unncessary always true test (src/backend/storage/buffer/bufmgr.c)