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