I thought about posting to pgsql-docs, but since this might require
comment from developers, I thought -general might be a better
starting point.
Anyway, I've occasionally run into monitoring situations where it
would be immediately helpful to know the built-in SQL statements that
generate given table-lock modes.
For instance, doesn't UPDATE implicitly mean that an ACCESS SHARE
lock will be taken if there are foreign keys involved (at least in
versions prior to 8.1)? Are there any other scenarios where a given
SQL command might take a lock of one of these forms as a result of
what it does under the hood? Maybe UPDATE is the only one since it's
implicitly a SELECT, DELETE, and INSERT all rolled into one.
I'd love to see 12.3 <http://www.postgresql.org/docs/8.0/static/
explicit-locking.html> document this more thoroughly, but I don't
know enough about the underlying locking requirements of each step of
each SQL command to know when locks might implicitly be acquired.
Even if UPDATE is the only special case, it seems like it'd be worth
mentioning.
--
Thomas F. O'Connell
Database Architecture and Programming
Co-Founder
Sitening, LLC
http://www.sitening.com/
110 30th Avenue North, Suite 6
Nashville, TN 37203-6320
615-469-5150
615-469-5151 (fax)
---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster
