It might not make much sense if you want to lock the rows only seldom, but it is technically possible to define the view with FOR UPDATE in it.

In my example, task has only one column, and I use a simple join condition, but the overall mechanism is the same:

CREATE OR REPLACE VIEW task_fu AS 
    SELECT t1.id 
      FROM task AS t1 
      LEFT JOIN task AS t2 ON t1.id * 10 = t2.id 
       FOR UPDATE OF t1 SKIP LOCKED;

Then, in one session, one can do

BEGIN;
BEGIN
SELECT * FROM task_fu LIMIT 5;
 id 
────
  1
  2
  3
  4
  5

While in another, this is what you get:

SELECT * FROM task_fu LIMIT 5;
 id 
────
  6
  7
  8
  9
 10

It might be important that if you happen to use an ORDER BY in the query (SELECT * FROM task_fu ORDER BY id LIMIT 5;), the second session will return 0 rows. The same is to be expected when the potential WHERE clauses would lock the same set of rows.

It might not make much sense if you want to lock the rows only seldom, but it is technically possible to define the view with FOR UPDATE OF in it.

In my example, task has only one column, and I use a simple join condition, but the overall mechanism is the same:

CREATE OR REPLACE VIEW task_fu AS 
    SELECT t1.id 
      FROM task AS t1 
      LEFT JOIN task AS t2 ON t1.id * 10 = t2.id 
       FOR UPDATE OF t1 SKIP LOCKED;

Then, in one session, one can do

BEGIN;
BEGIN
SELECT * FROM task_fu LIMIT 5;
 id 
────
  1
  2
  3
  4
  5

While in another, this is what you get:

SELECT * FROM task_fu LIMIT 5;
 id 
────
  6
  7
  8
  9
 10

It might be important that if you happen to use an ORDER BY in the query (SELECT * FROM task_fu ORDER BY id LIMIT 5;), the second session will return 0 rows. The same is to be expected when the potential WHERE clauses would lock the same set of rows.