Re: [17] CREATE SUBSCRIPTION ... SERVER

Jeff Davis <pgsql@j-davis.com>

From: Jeff Davis <pgsql@j-davis.com>
To: Ashutosh Bapat <ashutosh.bapat.oss@gmail.com>, Joe Conway <mail@joeconway.com>
Cc: pgsql-hackers@postgresql.org
Date: 2023-09-01T18:54:44Z
Lists: pgsql-hackers
On Fri, 2023-09-01 at 12:28 +0530, Ashutosh Bapat wrote:
> Thinking larger, how about we allow any FDW to be used here.

That's a possibility, but I think that means the subscription would
need to constantly re-check the parameters rather than relying on the
FDW's validator.

Otherwise it might be the wrong kind of FDW, and the user might be able
to circumvent the password_required protection. It might not even be a
postgres-related FDW at all, which would be a bit strange.

If it's constantly re-checking the parameters then it raises the
possibility that some "ALTER SERVER" or "ALTER USER MAPPING" succeeds
but then subscriptions to that foreign server start failing, which
would not be ideal. But I could be fine with that.

> But I think there's some value in bringing
> together these two subsystems which deal with foreign data logically
> (as in logical vs physical view of data).

I still don't understand how a core dependency on an extension would
work.

Regards,
	Jeff Davis




Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →
  1. Document new catalog columns, missed in commit 8185bb5347.

  2. Refactor to remove ForeignServerName().

  3. GetSubscription(): use per-object memory context.

  4. Fix dependency on FDW's connection function.

  5. ALTER SUBSCRIPTION ... SERVER test.

  6. Fix pg_dump for CREATE FOREIGN DATA WRAPPER ... CONNECTION.

  7. Clean up postgres_fdw/t/010_subscription.pl.

  8. CREATE SUBSCRIPTION ... SERVER.

  9. Allow upgrades to preserve the full subscription's state.