Postgres (and MySQL as well) provide a FOR UPDATE clause which instructs a SELECT operation to acquire row-level locks for the data it is reading.

We currently don't support this syntax, and supporting it with the same semantics is more or less impossible anyway with our underlying concurrency model (we have no locks, and while we could put "intents" in place to simulate an intent to write, it wouldn't quite be the same).

We should discuss whether we want to add least accept the syntax so that frameworks which make use of it can at least proceed (even if they don't get the intended semantics, though it's not clear what the implications of that are).

Apparently the Quartz scheduler makes use of SELECT FOR UPDATE. It is in this context that this came up.

See also http://www.postgresql.org/docs/9.1/static/explicit-locking.html for the explicit locking modes exposed by Postgres.