PostgreSQL - ON CONFLICT UPDATE with view with subset of columns - postgresql

Question

Currently running version 9.5.3. Update planned, of course.
I have a PostgreSQL database whose schema pre-dates table row-level security (i.e. CREATE POLICY ...). Row-level security was implemented using views. The security is done in the view by selecting only rows that have the ownername matching CURRENT_USER.
I'm trying to build an upsert query using such a view. The problem comes when I try to name the conflict_target.
The problem with using ON CONFLICT UPDATE ... comes from naming what constraint has been violated.
Toy Example
CREATE TABLE foo (id serial, num int, word text, data text, ownername varchar(64));
For each user, the combinations of word and num must be unique.
CREATE UNIQUE INDEX foo_num_word_owner_idx ON foo (num, word, ownername);
The row-level security is implemented using a view based on the current user name. Permission is granted for the view, and removed for the underlying table for ordinary user. security_barrier was added after v 9.5. Note that users don't see ownername.
CREATE VIEW foo_user WITH (security_barrier = True) AS
SELECT id, num, word, data FROM foo
WHERE foo.ownername = CURRENT_USER;
Now auto-set ownername:
CREATE OR REPLACE FUNCTION trf_set_owner() RETURNS trigger AS
$$
BEGIN
IF (TG_OP = 'INSERT') THEN
NEW.ownername = CURRENT_USER::varchar(64);
END IF;
IF (TG_OP = 'UPDATE') THEN
NEW.ownername = CURRENT_USER::varchar(64);
END IF;
RETURN NEW;
END;
$$
LANGUAGE 'plpgsql';
CREATE TRIGGER foo_row_owner
BEFORE INSERT OR UPDATE ON foo FOR EACH ROW
EXECUTE PROCEDURE trf_set_owner();
Note that the ownername column is not displayed in the view; the row security is invisible to the user.
Now add some data:
INSERT INTO foo_user (num, word, data) VALUES (1, 'asdf', 'cat'), (2, 'qwer', 'dog');
SELECT * FROM foo;
-- normally, this would give an error related to privileges,
-- because we don't allow users to query the underlying table.
-- bypassed here for demo purposes.
id | num | word | data | ownername
----+-----+------+------+-----------
1 | 1 | asdf | cat | admin
2 | 2 | qwer | dog | admin
(2 rows)
SELECT * FROM foo_user;
id | num | word | data
----+-----+------+------
1 | 1 | asdf | cat
2 | 2 | qwer | dog
(2 rows)
So far, so good.
What I've Tried
As stated above, for each user, num and word must be unique. There is no problem with different owners having the same num and word (in fact, we expect it).
I'm trying to take advantage of the ON CONFLICT clause in INSERT to create some back-end UPSERT-ish functionality. And it's falling down.
Simple example of error
First, a simple failed insert:
INSERT INTO foo_user (num, word, data) VALUES (2, 'qwer', 'frog');
ERROR: duplicate key value violates unique constraint "foo_num_word_owner_idx"
DETAIL: Key (num, word, ownername)=(2, qwer, admin) already exists.
Entirely expected. Nothing wrong with that.
ON CONFLICT, first attempt
Now we try to make the client experience a bit smoother:
INSERT INTO foo_user (num, word, data) VALUES (2, 'qwer', 'frog')
ON CONFLICT DO UPDATE
SET data = 'frog'
WHERE num = 2 AND word = 'qwer';
ERROR: ON CONFLICT DO UPDATE requires inference specification or constraint name
LINE 2: ON CONFLICT DO UPDATE
^
HINT: For example, ON CONFLICT (column_name).
Yep, just like the documentation says. It needs to know what rule it broke. No problem:
ON CONFLICT, second attempt
INSERT INTO foo_user (num, word, data) VALUES (2, 'qwer', 'frog')
ON CONFLICT (num, word, ownername) DO UPDATE
SET data = 'frog'
WHERE num = 2 AND word = 'qwer';
ERROR: column "ownername" does not exist
LINE 2: ON CONFLICT (num, word, ownername) DO UPDATE
True. Ownername does not exist in the view. We can't drop ownername from the unique index, because we fully expect different owners to have identical num and word values.
ON CONFLICT, third attempt
So I tried converting the index to a constraint, and naming the constraint:
ALTER TABLE foo
ADD CONSTRAINT foo_num_word_owner_crt UNIQUE
USING INDEX foo_num_word_owner_idx;
NOTICE: ALTER TABLE / ADD CONSTRAINT USING INDEX will rename index
"foo_num_word_owner_idx" to "foo_num_word_owner_crt"
Ok, now to test:
INSERT INTO foo_user (num, word, data) VALUES (2, 'qwer', 'frog')
ON CONFLICT ON CONSTRAINT foo_num_word_owner_crt DO UPDATE
SET data = 'frog'
WHERE num = 2 AND word = 'qwer';
ERROR: constraint "foo_num_word_owner_crt" for table "foo_user" does not exist
Well that makes sense: we're querying on the view but specifying a table constraint.
Conclusion
Now I'm out of ideas. How do we get ON CONFLICT to play nice with views like this? Or is it not possible?
I'm this close (holds up thumb and forefinger) to proposing we switch from views to tables with row-level security, but that's rather a lot of work (not necessarily an API-breaker, but still).
Any insights are much appreciated.

Answer 1

You can circumvent the issue by removing the ON CONFLICT clause and using an INSTEAD OF trigger that manually tests for any index conflict:
CREATE OR REPLACE FUNCTION trf_set_num_word() RETURNS trigger AS $$
BEGIN
-- Check if (num, word, ownername) exists by trying an UPDATE
UPDATE foo SET data = 'frog'
WHERE num = NEW.num AND word = NEW.word AND ownername = CURRENT_USER::varchar(64);
IF FOUND THEN
RETURN NULL; -- If so, don't INSERT/UPDATE
END IF;
RETURN NEW; -- If not, do the INSERT
END;
$$ LANGUAGE 'plpgsql';
CREATE TRIGGER foo_user_num_word
INSTEAD OF INSERT OR UPDATE ON foo_user FOR EACH ROW
EXECUTE PROCEDURE trf_set_num_word();