aboutsummaryrefslogtreecommitdiff
path: root/src/backend
diff options
context:
space:
mode:
authorTom Lane <tgl@sss.pgh.pa.us>2014-01-11 19:03:15 -0500
committerTom Lane <tgl@sss.pgh.pa.us>2014-01-11 19:03:15 -0500
commit27ff4cfe760a79c78eac2948cea67f2ae486cbbf (patch)
treef47dc4f947ed95b08bb0c1bdb8f5bdd2e16ed8b3 /src/backend
parent5bfcc9ec5e78733c5770c17d43c0315e0fcc14b9 (diff)
downloadpostgresql-27ff4cfe760a79c78eac2948cea67f2ae486cbbf.tar.gz
postgresql-27ff4cfe760a79c78eac2948cea67f2ae486cbbf.zip
Disallow LATERAL references to the target table of an UPDATE/DELETE.
On second thought, commit 0c051c90082da0b7e5bcaf9aabcbd4f361137cdc was over-hasty: rather than allowing this case, we ought to reject it for now. That leaves the field clear for a future feature that allows the target table to be re-specified in the FROM (or USING) clause, which will enable left-joining the target table to something else. We can then also allow LATERAL references to such an explicitly re-specified target table. But allowing them right now will create ambiguities or worse for such a feature, and it isn't something we documented 9.3 as supporting. While at it, add a convenience subroutine to avoid having several copies of the ereport for disalllowed-LATERAL-reference cases.
Diffstat (limited to 'src/backend')
-rw-r--r--src/backend/parser/analyze.c12
-rw-r--r--src/backend/parser/parse_relation.c62
2 files changed, 45 insertions, 29 deletions
diff --git a/src/backend/parser/analyze.c b/src/backend/parser/analyze.c
index 2d8dc57d690..7c31b9d65e8 100644
--- a/src/backend/parser/analyze.c
+++ b/src/backend/parser/analyze.c
@@ -367,8 +367,9 @@ transformDeleteStmt(ParseState *pstate, DeleteStmt *stmt)
/* there's no DISTINCT in DELETE */
qry->distinctClause = NIL;
- /* subqueries in USING can see the result relation only via LATERAL */
+ /* subqueries in USING cannot access the result relation */
nsitem->p_lateral_only = true;
+ nsitem->p_lateral_ok = false;
/*
* The USING clause is non-standard SQL syntax, and is equivalent in
@@ -378,8 +379,9 @@ transformDeleteStmt(ParseState *pstate, DeleteStmt *stmt)
*/
transformFromClause(pstate, stmt->usingClause);
- /* remaining clauses can see the result relation normally */
+ /* remaining clauses can reference the result relation normally */
nsitem->p_lateral_only = false;
+ nsitem->p_lateral_ok = true;
qual = transformWhereClause(pstate, stmt->whereClause,
EXPR_KIND_WHERE, "WHERE");
@@ -1925,8 +1927,9 @@ transformUpdateStmt(ParseState *pstate, UpdateStmt *stmt)
/* grab the namespace item made by setTargetTable */
nsitem = (ParseNamespaceItem *) llast(pstate->p_namespace);
- /* subqueries in FROM can see the result relation only via LATERAL */
+ /* subqueries in FROM cannot access the result relation */
nsitem->p_lateral_only = true;
+ nsitem->p_lateral_ok = false;
/*
* the FROM clause is non-standard SQL syntax. We used to be able to do
@@ -1934,8 +1937,9 @@ transformUpdateStmt(ParseState *pstate, UpdateStmt *stmt)
*/
transformFromClause(pstate, stmt->fromClause);
- /* remaining clauses can see the result relation normally */
+ /* remaining clauses can reference the result relation normally */
nsitem->p_lateral_only = false;
+ nsitem->p_lateral_ok = true;
qry->targetList = transformTargetList(pstate, stmt->targetList,
EXPR_KIND_UPDATE_SOURCE);
diff --git a/src/backend/parser/parse_relation.c b/src/backend/parser/parse_relation.c
index 8bd3a90feaf..e2cfa990780 100644
--- a/src/backend/parser/parse_relation.c
+++ b/src/backend/parser/parse_relation.c
@@ -38,6 +38,8 @@ static RangeTblEntry *scanNameSpaceForRefname(ParseState *pstate,
const char *refname, int location);
static RangeTblEntry *scanNameSpaceForRelid(ParseState *pstate, Oid relid,
int location);
+static void check_lateral_ref_ok(ParseState *pstate, ParseNamespaceItem *nsitem,
+ int location);
static void markRTEForSelectPriv(ParseState *pstate, RangeTblEntry *rte,
int rtindex, AttrNumber col);
static void expandRelation(Oid relid, Alias *eref,
@@ -170,14 +172,7 @@ scanNameSpaceForRefname(ParseState *pstate, const char *refname, int location)
errmsg("table reference \"%s\" is ambiguous",
refname),
parser_errposition(pstate, location)));
- /* SQL:2008 demands this be an error, not an invisible item */
- if (nsitem->p_lateral_only && !nsitem->p_lateral_ok)
- ereport(ERROR,
- (errcode(ERRCODE_INVALID_COLUMN_REFERENCE),
- errmsg("invalid reference to FROM-clause entry for table \"%s\"",
- refname),
- errdetail("The combining JOIN type must be INNER or LEFT for a LATERAL reference."),
- parser_errposition(pstate, location)));
+ check_lateral_ref_ok(pstate, nsitem, location);
result = rte;
}
}
@@ -221,14 +216,7 @@ scanNameSpaceForRelid(ParseState *pstate, Oid relid, int location)
errmsg("table reference %u is ambiguous",
relid),
parser_errposition(pstate, location)));
- /* SQL:2008 demands this be an error, not an invisible item */
- if (nsitem->p_lateral_only && !nsitem->p_lateral_ok)
- ereport(ERROR,
- (errcode(ERRCODE_INVALID_COLUMN_REFERENCE),
- errmsg("invalid reference to FROM-clause entry for table \"%s\"",
- rte->eref->aliasname),
- errdetail("The combining JOIN type must be INNER or LEFT for a LATERAL reference."),
- parser_errposition(pstate, location)));
+ check_lateral_ref_ok(pstate, nsitem, location);
result = rte;
}
}
@@ -411,6 +399,37 @@ checkNameSpaceConflicts(ParseState *pstate, List *namespace1,
}
/*
+ * Complain if a namespace item is currently disallowed as a LATERAL reference.
+ * This enforces both SQL:2008's rather odd idea of what to do with a LATERAL
+ * reference to the wrong side of an outer join, and our own prohibition on
+ * referencing the target table of an UPDATE or DELETE as a lateral reference
+ * in a FROM/USING clause.
+ *
+ * Convenience subroutine to avoid multiple copies of a rather ugly ereport.
+ */
+static void
+check_lateral_ref_ok(ParseState *pstate, ParseNamespaceItem *nsitem,
+ int location)
+{
+ if (nsitem->p_lateral_only && !nsitem->p_lateral_ok)
+ {
+ /* SQL:2008 demands this be an error, not an invisible item */
+ RangeTblEntry *rte = nsitem->p_rte;
+ char *refname = rte->eref->aliasname;
+
+ ereport(ERROR,
+ (errcode(ERRCODE_INVALID_COLUMN_REFERENCE),
+ errmsg("invalid reference to FROM-clause entry for table \"%s\"",
+ refname),
+ (rte == pstate->p_target_rangetblentry) ?
+ errhint("There is an entry for table \"%s\", but it cannot be referenced from this part of the query.",
+ refname) :
+ errdetail("The combining JOIN type must be INNER or LEFT for a LATERAL reference."),
+ parser_errposition(pstate, location)));
+ }
+}
+
+/*
* given an RTE, return RT index (starting with 1) of the entry,
* and optionally get its nesting depth (0 = current). If sublevels_up
* is NULL, only consider rels at the current nesting level.
@@ -622,15 +641,8 @@ colNameToVar(ParseState *pstate, char *colname, bool localonly,
(errcode(ERRCODE_AMBIGUOUS_COLUMN),
errmsg("column reference \"%s\" is ambiguous",
colname),
- parser_errposition(orig_pstate, location)));
- /* SQL:2008 demands this be an error, not an invisible item */
- if (nsitem->p_lateral_only && !nsitem->p_lateral_ok)
- ereport(ERROR,
- (errcode(ERRCODE_INVALID_COLUMN_REFERENCE),
- errmsg("invalid reference to FROM-clause entry for table \"%s\"",
- rte->eref->aliasname),
- errdetail("The combining JOIN type must be INNER or LEFT for a LATERAL reference."),
- parser_errposition(orig_pstate, location)));
+ parser_errposition(pstate, location)));
+ check_lateral_ref_ok(pstate, nsitem, location);
result = newresult;
}
}