Re: ALTER TABLE lock strength reduction patch is unsafe Reply-To:

On 21 March 2014 17:49, Noah Misch <noah(at)leadboat(dot)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 find it hard to justify why we accept such a statement. Surely its a
>> bug when the named table turns out to be a view? Presumably ALTER
>> SEQUENCE and ALTER <other stuff> has checks for the correct object
>> type? OMG.
>
> We've framed ALTER TABLE's relkind leniency as a historic artifact. As a move
> toward stricter checks, ALTER TABLE refused to operate on foreign tables in
> 9.1 and 9.2. 9.3 reversed that course, though. For better or worse, ALTER
> TABLE is nearly a union of the relation ALTER possibilities. That choice is
> well-entrenched.

By "well entrenched", I think you mean undocumented, untested, unintentional?

Do we think anyone *relies* on being able to say the word TABLE when
in fact they mean VIEW or SEQUENCE?

How is that artefact anything but a bug? i.e. is anyone going to stop
me fixing it?

--
Simon Riggs http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services