Does the combination in $SUBJECT make sense? It is currently allowed,
but of course the underlying locks only last while the creating
transaction is open, and they are reacquired during a refresh.
Somewhat related is that the error message they emit is a bit
nonstandard:
cannot lock rows in materialized view \"%s\"
After checking the reason for this, I noticed that it doesn't even match
what the code thinks it should (CheckValidRowMarkRel()):
case RELKIND_MATVIEW:
/* Should not get here */
ereport(ERROR,
(errcode(ERRCODE_WRONG_OBJECT_TYPE),
errmsg("cannot lock rows in
materialized view \"%s\"",
RelationGetRelationName(rel))));
apparently this function believes that the check should be applied
earlier, but it isn't. I think we ought to either add a check to the
parser stage; *or* we should remove the "should not get here" comment.
I also propose we make these errors consistent with the wording of the
other related errors, i.e. "FOR UPDATE is not allowed with materialized
views", and of course change it for all the other cases in that
function.
Opinions?
--
Álvaro Herrera http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
