Re: "ORDER BY" clause prevents "UPDATE WHERE CURRENT OF"

From: "Robert Haas" <robertmhaas(at)gmail(dot)com>
To: "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: "Gregory Stark" <stark(at)enterprisedb(dot)com>, Postgres <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: "ORDER BY" clause prevents "UPDATE WHERE CURRENT OF"
Date: 2008-11-15 01:24:00
Message-ID: 603c8f070811141724w6ef8fe82ic25c929672c2bb60@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

> However ... the more I think about it, the more I wonder if we shouldn't
> rip out the current search-the-plan-tree hack and allow WHERE CURRENT OF
> *only* for cursors that say FOR UPDATE. Aside from the above issue,
> there's an already known and documented risk if you omit FOR UPDATE,
> which is that your WHERE CURRENT OF update silently becomes a no-op
> if someone else has already updated the target row since your query
> started. It seems like not using FOR UPDATE is sufficiently dangerous
> practice that requiring it wouldn't be doing our users a disservice.

Yes, I was reading that documentation today and scratching my head.
It didn't quite dawn on me that the solution was to just always use
FOR UPDATE, but certainly if it is then you may as well enforce it.
I've encountered that no-op behavior in other situations in the past,
specifically BEFORE triggers, and it's really weird and confusing,
because you typically have to be doing something fairly complicated
before the problem case arises, and then it mysteriously fails to
work.

...Robert

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2008-11-15 01:29:39 Re: Synchronous replication patch v2
Previous Message ITAGAKI Takahiro 2008-11-15 01:20:00 Re: auto_explain contrib moudle