On 2017-02-13 12:05:21 -0500, Robert Haas wrote: > On Fri, Feb 10, 2017 at 8:39 PM, Peter Geoghegan <p...@bowt.ie> wrote: > > On Thu, Feb 9, 2017 at 2:32 PM, Andres Freund <and...@anarazel.de> wrote: > >> Except that the proposed names aren't remotely like that... ;). > > > > Revision attached -- V5. We now REVOKE ALL on both functions, as > > Robert suggested, instead of the previous approach of having a > > hard-coded superuser check with enforcement. > > > >> And I proposed documenting named parameters, and > >> check_btree(performing_check_requiring_exclusive_locks => true) is just > >> about as expressive. > > > > I have not done this, nor have I renamed the functions. I still think > > that this is something that we can fix by adding a boolean argument to > > each function in the future, or something along those lines. I > > *really* hate the idea of having one function with non-obvious, > > variable requirements on locking, with locking implications that are > > not knowable when we PREPARE an SQL statement calling the function. It > > also removes a useful way of have superusers discriminate against the > > stronger locking variant bt_index_parent_check() by not granting > > execute on it (as an anti-footgun measure). > > I think Andres is more or less correct that > "performing_check_requiring_exclusive_locks => true" is just about as > expressive as calling a different function, but I think that your > point that the superuser might want to grant access to one function > but not the other is a good one. On the other hand, I think Andres > has a concern that we might have more modes in the future and we don't > want to end up with 2^n entrypoints. That also seems valid. Hmm.
That's part of my concern. The second part is that I really want to be able to have a check_relation() (and check_database())function that I can pass a bunch of arguments determining how expensive checks are going to be performed. E.g. I'd like to be able to do something like SELECT * FROM check_relation( 'my_table'::regclass, test_btree => 'true', test_btree_heap_interlock => 'true', test_gin => 'true'); SELECT * FROM check_current_database( test_heap_update_chains => 'true', test_heap_clog_interlock => 'true', test_btree => 'true', test_gin => 'false'); etc. You can't really trivially replace these with a larger query and/or function, because of the locking considerations (consider what happens if somebody concurrently drops a table/index - your whole query errors out, wasting hours of work). I'm ok with not immediately doing so, but I think Peter's design isn't in line with achieving something like this. Regards, Andres -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
