Horton
Menu

Re: Non-superuser subscription owners

Jeff Davis <pgsql@j-davis.com>

View thread
From: Jeff Davis <pgsql@j-davis.com>
To: Robert Haas <robertmhaas@gmail.com>
Cc: Andres Freund <andres@anarazel.de>, Mark Dilger <mark.dilger@enterprisedb.com>, Amit Kapila <amit.kapila16@gmail.com>, Andrew Dunstan <andrew@dunslane.net>, PostgreSQL-development <pgsql-hackers@postgresql.org>
Date: 2023-03-01T22:27:25Z
Lists: pgsql-hackers 
On Wed, 2023-03-01 at 16:06 -0500, Robert Haas wrote:

> To be fair, it's possible that there's no solution to this class of
> problems that *doesn't* suck, but I think we should look a lot harder
> before coming to that conclusion.

Fair enough. The situation is bad enough that I'm willing to consider a
pretty wide range of solutions and mitigations that might otherwise be
unappealing.

I think there might be something promising in your idea to highly
restrict the privileges of code attached to a table. A lot of
expressions are really simple and don't need much to be both useful and
safe. We may not need the exact same solution for both default
expressions and triggers. Some details to work through, though.

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. Fix possible crash in tablesync worker.

  2. Display 'password_required' option for \dRs+ command.

  3. Restart the apply worker if the 'password_required' option is changed.

  4. Fix possible logical replication crash.

  5. Add new predefined role pg_create_subscription.

  6. Expand AclMode to 64 bits

  7. More cleanup of a2ab9c06ea.

  8. Respect permissions within logical replication.

  9. Improve table locking behavior in the face of current DDL.