On Fri, 2011-01-07 at 08:16 -0500, Robert Haas wrote:
> One of the things that I ripped out of the SQL/MED syntax patch before
> committing it was the hack that made LOCK TABLE also work on FOREIGN
> TABLEs. Since we're treating a foreign table as a different kind of
> object than a TABLE in some places, we shouldn't confuse the two
> things elsewhere, at least in my opinion. I also noticed that pg_dump
> has the following comment:
>
> * NOTE: it'd be kinda nice to lock other relations
> too, not only
> * plain tables, but the backend doesn't presently
> allow that.
>
> This is pretty trivial from a backend point of view, especially with
> the new objectaddress.c machinery.
I'm not clear why we'd want to do that. We shouldn't just be adding
things because we can do them easily, we should be adding things with a
clear use case or a standardization requirement.
If anyone suggested tuning some aspect of the code, yet offered no
evidence that it was ever important, it would get shot down. Why is this
any different?
Allowing LOCK on views would significantly undermine admin structures
where the only access to a table is via a view. This would allow people
to lock objects they didn't previously have access to and seems likely
to introduce more contention into applications as a result.
-- Simon Riggs http://www.2ndQuadrant.com/books/PostgreSQL Development, 24x7 Support, Training and Services
