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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers