Re: [HACKERS] Simplify ACL handling for large objects and removal of superuser() checks
От | Tom Lane |
---|---|
Тема | Re: [HACKERS] Simplify ACL handling for large objects and removal of superuser() checks |
Дата | |
Msg-id | 1908.1510175127@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: [HACKERS] Simplify ACL handling for large objects and removal ofsuperuser() checks (Michael Paquier <michael.paquier@gmail.com>) |
Ответы |
Re: [HACKERS] Simplify ACL handling for large objects and removal ofsuperuser() checks
|
Список | pgsql-hackers |
Michael Paquier <michael.paquier@gmail.com> writes: > On Tue, Sep 26, 2017 at 11:42 AM, Vaishnavi Prabakaran > <vaishnaviprabakaran@gmail.com> wrote: >> I moved the cf entry to "ready for committer", and though my vote is for >> keeping the existing API behavior with write implying read, I let the >> committer decide whether the following behavior change is Ok or not. >> "Reading from a large-object descriptor opened with INV_WRITE is NOT >> possible" > Thanks for the review! After chewing on this some more, I'm inclined to agree that we should not change the behavior of the read/write flags. There's been no field requests for a true-write-only mode, so I think we're much more likely to get complaints from users whose code we broke than plaudits from people who think the change is helpful. I believe it would be easy enough to adjust the patch so that we can still have the refactoring benefits; we'd just need the bit that translates from external to internal flags to go more like if (flags & INV_WRITE) descflags |= IFS_WRLOCK | IFS_RDLOCK;if (flags & INV_READ) descflags |= IFS_RDLOCK; (Preferably with a comment about why it's like this.) Another idea would be to invent a new external flag bit "INV_WRITE_ONLY", so that people who wanted true write-only could get it, without breaking backwards-compatible behavior. But I'm inclined to wait for some field demand to show up before adding even that little bit of complication. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
В списке pgsql-hackers по дате отправления: