* Josh Kupershmidt: > On Wed, Jun 29, 2011 at 7:48 AM, Florian Weimer <fweimer@xxxxxx> wrote: >> I've been looking around in the 9.0 documentation, but couldn't find the >> permission requirements for LOCK TABLE (in particular, LOCK TABLE IN >> SHARE MODE). From the source, you need at least one of UPDATE, DELETE >> or TRUNCATE. >> >> Is there a reason why the INSERT privilege is not sufficient for LOCK >> TABLE, or is this just an oversight? > > The comments on this thread outline some reasons the permissions for > LOCK TABLE are setup the way they are: > http://archives.postgresql.org/pgsql-hackers/2010-11/msg01819.php > > Basically, if you have UPDATE, DELETE, or TRUNCATE privileges you can > potentially lock out competing sessions on a table, similar to what > some forms of LOCK TABLE would do; just having INSERT privileges > doesn't necessarily give you that power. This makes sense, thanks. Doesn't REFERENCES have the same potential? Then it could be added to the list. In my pre-9.1 world, I need to acquire a table lock to avoid incorrectly serialized transactions. The application is only doing SELECTs and INSERTs, so I don't want to grant it UPDATE privileges, but REFERENCES would be fine. Right now, I'm using a separate, empty table and lock that, but that's a bit of a kludge. -- Florian Weimer <fweimer@xxxxxx> BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstraße 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99 -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
