Re: Non-superuser subscription owners
Jeff Davis <pgsql@j-davis.com>
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-27T22:17:27Z
Lists: pgsql-hackers
On Mon, 2023-03-27 at 14:06 -0400, Robert Haas wrote: > I thought you were asking for those changes to be made before this > patch got committed, so that's what I was responding to. If you're > asking for it not to be committed at all, that's a different > discussion. I separately had a complaint (in a separate subthread) about the scope of the predefined role you are introducing, which I think encompasses two concepts that should be treated differently and I think that may need to be revisited later. If you ignore this complaint it wouldn't be the end of the world. This subthread is about the order in which the patches get committed (which is a topic you brought up), not whether they are ever to be committed. > > I kind of agree with you about the feature itself. Even though the > basic feature works quite well and does something people really want, > there are a lot of loose ends to sort out, and not just about > security. But I also want to make some progress. If there are > problems > with what I'm proposing that will make us regret committing things > right before feature freeze, then we shouldn't. But waiting a whole > additional year to see any kind of improvement is not free; these > issues are serious. The non-superuser-subscription-owner patch without the apply-as-table- owner patch feels like a facade to me, at least right now. Perhaps I can be convinced otherwise, but that's what it looks like to me. > > I think this patch is a lot better-baked and less speculative than > that one. I think that patch is more important, so if they were > equally mature, I'd favor getting that one committed first. But > that's > not the case. You explicitly asked about the order of the patches, which made me think it was more of an option? If the apply-as-table-owner patch gets held up for whatever reason, we might have to make a difficult decision. I'd prefer focus on the apply- as-table-owner patch briefly, and now that it's getting some review attention, we might find out how ready it is quite soon. 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 →
-
Fix possible crash in tablesync worker.
- b5c517379a40 16.0 landed
-
Display 'password_required' option for \dRs+ command.
- 19e65dff38bd 16.0 landed
-
Restart the apply worker if the 'password_required' option is changed.
- c1cc4e688b60 16.0 landed
-
Fix possible logical replication crash.
- e7e7da2f8d57 16.0 landed
-
Add new predefined role pg_create_subscription.
- c3afe8cf5a1e 16.0 landed
-
Expand AclMode to 64 bits
- 7b378237aa80 16.0 cited
-
More cleanup of a2ab9c06ea.
- 96a6f11c0625 15.0 landed
-
Respect permissions within logical replication.
- a2ab9c06ea15 15.0 landed
-
Improve table locking behavior in the face of current DDL.
- 2ad36c4e44c8 9.2.0 cited