CREATE MATERIALIZED VIEW .. FOR UPDATE

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

Responses

Browse pgsql-hackers by date

  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