From bf4052faa1c289883799d49f063715161a8a4f1e Mon Sep 17 00:00:00 2001 From: Tom Lane Date: Thu, 6 Mar 2014 11:37:02 -0500 Subject: Don't reject ROW_MARK_REFERENCE rowmarks for materialized views. We should allow this so that matviews can be referenced in UPDATE/DELETE statements in READ COMMITTED isolation level. The requirement for that is that a re-fetch by TID will see the same row version the query saw earlier, which is true of matviews, so there's no reason for the restriction. Per bug #9398. Michael Paquier, after a suggestion by me --- src/backend/executor/execMain.c | 13 +++++++------ 1 file changed, 7 insertions(+), 6 deletions(-) (limited to 'src/backend/executor/execMain.c') diff --git a/src/backend/executor/execMain.c b/src/backend/executor/execMain.c index 6b5f198c054..9e3d879ae77 100644 --- a/src/backend/executor/execMain.c +++ b/src/backend/executor/execMain.c @@ -1102,14 +1102,15 @@ CheckValidRowMarkRel(Relation rel, RowMarkType markType) RelationGetRelationName(rel)))); break; case RELKIND_MATVIEW: - /* Should not get here */ - ereport(ERROR, - (errcode(ERRCODE_WRONG_OBJECT_TYPE), - errmsg("cannot lock rows in materialized view \"%s\"", - RelationGetRelationName(rel)))); + /* Allow referencing a matview, but not actual locking clauses */ + if (markType != ROW_MARK_REFERENCE) + ereport(ERROR, + (errcode(ERRCODE_WRONG_OBJECT_TYPE), + errmsg("cannot lock rows in materialized view \"%s\"", + RelationGetRelationName(rel)))); break; case RELKIND_FOREIGN_TABLE: - /* Should not get here */ + /* Should not get here; planner should have used ROW_MARK_COPY */ ereport(ERROR, (errcode(ERRCODE_WRONG_OBJECT_TYPE), errmsg("cannot lock rows in foreign table \"%s\"", -- cgit v1.2.3