On 21 March 2014 16:11, Simon Riggs <simon@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