|
8 | 8 | * |
9 | 9 | * |
10 | 10 | * IDENTIFICATION |
11 | | - * $Header: /cvsroot/pgsql/src/backend/optimizer/plan/initsplan.c,v 1.60 2001/05/07 00:43:21 tgl Exp $ |
| 11 | + * $Header: /cvsroot/pgsql/src/backend/optimizer/plan/initsplan.c,v 1.61 2001/05/14 20:25:00 tgl Exp $ |
12 | 12 | * |
13 | 13 | *------------------------------------------------------------------------- |
14 | 14 | */ |
@@ -298,14 +298,30 @@ mark_baserels_for_outer_join(Query *root, Relids rels, Relids outerrels) |
298 | 298 |
|
299 | 299 | foreach(relid,rels) |
300 | 300 | { |
301 | | -RelOptInfo*rel=get_base_rel(root,lfirsti(relid)); |
| 301 | +intrelno=lfirsti(relid); |
| 302 | +RelOptInfo*rel=get_base_rel(root,relno); |
302 | 303 |
|
303 | 304 | /* |
304 | 305 | * Since we do this bottom-up, any outer-rels previously marked |
305 | 306 | * should be within the new outer join set. |
306 | 307 | */ |
307 | 308 | Assert(is_subseti(rel->outerjoinset,outerrels)); |
308 | 309 |
|
| 310 | +/* |
| 311 | + * Presently the executor cannot support FOR UPDATE marking of |
| 312 | + * rels appearing on the nullable side of an outer join. |
| 313 | + * (It's somewhat unclear what that would mean, anyway: what should |
| 314 | + * we mark when a result row is generated from no element of the |
| 315 | + * nullable relation?) So, complain if target rel is FOR UPDATE. |
| 316 | + * It's sufficient to make this check once per rel, so do it only |
| 317 | + * if rel wasn't already known nullable. |
| 318 | + */ |
| 319 | +if (rel->outerjoinset==NIL) |
| 320 | +{ |
| 321 | +if (intMember(relno,root->rowMarks)) |
| 322 | +elog(ERROR,"SELECT FOR UPDATE cannot be applied to the nullable side of an OUTER JOIN"); |
| 323 | +} |
| 324 | + |
309 | 325 | rel->outerjoinset=outerrels; |
310 | 326 | } |
311 | 327 | } |
|