On 21 March 2014 16:11, Simon Riggs <si...@2ndquadrant.com> wrote: >>> + * Be careful to ensure this function is called for Tables and Indexes >>> only. >>> + * It is not currently safe to be called for Views because security_barrier >>> + * is listed as an option and so would be allowed to be set at a level >>> lower >>> + * than AccessExclusiveLock, which would not be correct. >> >> This statement is accepted and takes only ShareUpdateExclusiveLock: >> >> alter table information_schema.triggers set (security_barrier = true);
>> I suggest adding a LOCKMODE field to relopt_gen and adding a >> reloptions_locklevel() function to determine the required level from an >> options list. That puts control of the lock level near the code that >> understands the implications for each option. You can then revert the >> addition of AlterViewInternal() and some of the utility.c changes. > > Sure, that's how we code it, but I'm not sure we should introduce that > feature. The above weirdness is not itself justification. OK, will follow this path. It's a good idea since it encourages authors of new "options" to consider properly the lock level that will be required. -- Simon Riggs http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
