aboutsummaryrefslogtreecommitdiff
path: root/src/backend/rewrite/rewriteHandler.c
diff options
context:
space:
mode:
authorTom Lane <tgl@sss.pgh.pa.us>2009-10-27 17:11:30 +0000
committerTom Lane <tgl@sss.pgh.pa.us>2009-10-27 17:11:30 +0000
commitbd02b48ba44c6e0593320a9c3e071ba78efe1c04 (patch)
treee7707af135ae9d537dbd43fe38c8aa5a46b9b25a /src/backend/rewrite/rewriteHandler.c
parent0dfba4e98f7ef724839a6f446d96040645b9b487 (diff)
downloadpostgresql-bd02b48ba44c6e0593320a9c3e071ba78efe1c04.tar.gz
postgresql-bd02b48ba44c6e0593320a9c3e071ba78efe1c04.zip
Make FOR UPDATE/SHARE in the primary query not propagate into WITH queries;
for example in WITH w AS (SELECT * FROM foo) SELECT * FROM w, bar ... FOR UPDATE the FOR UPDATE will now affect bar but not foo. This is more useful and consistent than the original 8.4 behavior, which tried to propagate FOR UPDATE into the WITH query but always failed due to assorted implementation restrictions. Even though we are in process of removing those restrictions, it seems correct on philosophical grounds to not let the outer query's FOR UPDATE affect the WITH query. In passing, fix isLockedRel which frequently got things wrong in nested-subquery cases: "FOR UPDATE OF foo" applies to an alias foo in the current query level, not subqueries. This has been broken for a long time, but it doesn't seem worth back-patching further than 8.4 because the actual consequences are minimal. At worst the parser would sometimes get RowShareLock on a relation when it should be AccessShareLock or vice versa. That would only make a difference if someone were using ExclusiveLock concurrently, which no standard operation does, and anyway FOR UPDATE doesn't result in visible changes so it's not clear that the someone would notice any problem. Between that and the fact that FOR UPDATE barely works with subqueries at all in existing releases, I'm not excited about worrying about it.
Diffstat (limited to 'src/backend/rewrite/rewriteHandler.c')
-rw-r--r--src/backend/rewrite/rewriteHandler.c32
1 files changed, 2 insertions, 30 deletions
diff --git a/src/backend/rewrite/rewriteHandler.c b/src/backend/rewrite/rewriteHandler.c
index b3a18134539..89ef9a356d2 100644
--- a/src/backend/rewrite/rewriteHandler.c
+++ b/src/backend/rewrite/rewriteHandler.c
@@ -7,7 +7,7 @@
* Portions Copyright (c) 1994, Regents of the University of California
*
* IDENTIFICATION
- * $PostgreSQL: pgsql/src/backend/rewrite/rewriteHandler.c,v 1.186.2.1 2009/09/02 17:52:33 tgl Exp $
+ * $PostgreSQL: pgsql/src/backend/rewrite/rewriteHandler.c,v 1.186.2.2 2009/10/27 17:11:30 tgl Exp $
*
*-------------------------------------------------------------------------
*/
@@ -1242,35 +1242,7 @@ markQueryForLocking(Query *qry, Node *jtnode, bool forUpdate, bool noWait)
markQueryForLocking(rte->subquery, (Node *) rte->subquery->jointree,
forUpdate, noWait);
}
- else if (rte->rtekind == RTE_CTE)
- {
- /*
- * We allow FOR UPDATE/SHARE of a WITH query to be propagated into
- * the WITH, but it doesn't seem very sane to allow this for a
- * reference to an outer-level WITH (compare
- * transformLockingClause). Which simplifies life here.
- */
- CommonTableExpr *cte = NULL;
- ListCell *lc;
-
- if (rte->ctelevelsup > 0 || rte->self_reference)
- ereport(ERROR,
- (errcode(ERRCODE_FEATURE_NOT_SUPPORTED),
- errmsg("SELECT FOR UPDATE/SHARE cannot be applied to an outer-level WITH query")));
- foreach(lc, qry->cteList)
- {
- cte = (CommonTableExpr *) lfirst(lc);
- if (strcmp(cte->ctename, rte->ctename) == 0)
- break;
- }
- if (lc == NULL) /* shouldn't happen */
- elog(ERROR, "could not find CTE \"%s\"", rte->ctename);
- /* should be analyzed by now */
- Assert(IsA(cte->ctequery, Query));
- markQueryForLocking((Query *) cte->ctequery,
- (Node *) ((Query *) cte->ctequery)->jointree,
- forUpdate, noWait);
- }
+ /* other RTE types are unaffected by FOR UPDATE */
}
else if (IsA(jtnode, FromExpr))
{