This is exactly what I worried about, and having it arrive so long after
feature freeze, there is no time to recover.  I will hold it for 7.5. 
Thanks for the analysis.  Sorry, Gavin.  Saved to 7.5 open items queue.


Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Can I get some comments on this?
> It's far from ready for prime time :-(
> The main problem with it is it's doing the wrong things in the wrong
> places.  The key part of the patch is a hack in parse_expr.c to
> transform "WHERE CURRENT OF cursor" into "WHERE ctid = <tid constant>",
> where the TID constant has been obtained by reaching into the cursor and
> grabbing the current position.  Parse analysis is entirely the wrong
> time to be doing that --- in any context where the statement will not be
> executed immediately, there is no good reason to expect that the cursor
> even exists, let alone is positioned at the row it will be positioned at
> when you finally execute the query.  This approach cannot support WHERE
> CURRENT OF in plpgsql functions, rules, or prepared statements.
> A lesser but still fatal objection is that the rule reverse-lister would
> show the query as "WHERE ctid = <tid constant>" rather than "WHERE
> AFAICS, WHERE CURRENT OF has to be a construct that propagates in just
> that form all the way into the executor (with a hack in the planner to
> ensure that a TidScan plan is chosen) and then the reaching into the
> cursor has to happen at plan startup in nodeTidscan.c.
> The business with a substitute snapshot seems pretty dubious too.  It
> looks like a cursor that started with a normal snapshot --- some
> transactions visible, some not --- will suddenly flip into SnapshotNow
> except for the specific row(s) updated by the current transaction.
> That's not gonna do.  In the first place, only rows updated *through
> that cursor* ought to change visibility, according to my reading of the
> spec.  In the second place, SnapshotNow will allow visibility of
> external transactions that should not have been visible according to the
> original snapshot.
> I don't understand what the diffs in postgres.c are supposed to
> accomplish, but I can just about promise that they are misplaced too,
> since they won't affect queries executed via functions or SPI.
>                       regards, tom lane

  Bruce Momjian                        |
  [EMAIL PROTECTED]               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

---------------------------(end of broadcast)---------------------------
TIP 3: if posting/reading through Usenet, please send an appropriate
      subscribe-nomail command to [EMAIL PROTECTED] so that your
      message can get through to the mailing list cleanly

Reply via email to