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
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 |