From: | Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> |
---|---|
To: | Pg Hackers <pgsql-hackers(at)postgresql(dot)org> |
Cc: | Kevin Grittner <kgrittn(at)ymail(dot)com> |
Subject: | CREATE MATERIALIZED VIEW .. FOR UPDATE |
Date: | 2013-08-02 16:46:33 |
Message-ID: | 20130802164633.GA16005@eldon.alvh.no-ip.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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
From | Date | Subject | |
---|---|---|---|
Next Message | Alvaro Herrera | 2013-08-02 17:34:58 | Re: Re: ALTER SYSTEM SET command to change postgresql.conf parameters (RE: Proposal for Allow postgresql.conf values to be changed via SQL [review]) |
Previous Message | Kodamasimham Pridhvi (MT2012066) | 2013-08-02 16:06:02 | Need help to begin contribution in PostgreSQL Development - Specifically XML module |