Idea: lock_timeout scoped by lock types

Hello,

We've put a lot of effort (as I know many others have) into ensuring
any DDL we run in production doesn't block (or, at least, doesn't
block for more than a very short amount of time). That includes the
obvious: e.g., don't do operations that require rewriting or scanning
a large table under an exclusive lock. Another key piece is relying on
a small lock_timeout value to ensure that when we do take out
exclusive locks we don't cause a large amount of queuing by having the
AccessExclusiveLock acquisition itself queued behind a long-running
query.

In our normal use setting lock_timeout happens inside libraries so we
don't have to think about it, but occasionally we have a use case that
isn't using those libraries, and that creates a foot-gun for us.

The obvious question would be: why not just set lock_timeout globally?
In practice that's not necessarily reasonable because it applies
equally to all lock types. A couple of examples:

- Table level: SELECTs or UPDATEs queue on a short-lived exclusive
lock: we don't want to timeout lock acquisition on these at all.
- Row level: we want to allow updates to the same rows (e.g.,
different columns, non conflicting) to execute sequentially without a
lock timeout.

But we don't want to allow reads or writes to queue for more than a
few seconds behind AccessExclusiveLock or even ShareLock.

I'm wondering if adding the ability to configure lock_timeout at a
more granular level is something that would be a reasonable solution
to this problem, or if folks think there's a better way to solve the
problem.

Regards,
James Coleman