Martijn van Oosterhout wrote:
thnx a lot. But it does not work as expected cause the update-statement
ist not commiting for the whole table during the execution. So the
resulting order can be different from the original order, which is what
I try to avoid.
Well, that's because you're typing the query wrong. Because you said:
where t2.id <= voev_content.id
It's going to order them by the id (which you didn't show in your query
which is why it's not obvious). If you want to order by rank you should
do (your query search-replace id for rank):
;) thnx a lot. While I was reading the manuals to reveal the secrets of
transaction-levels in update-operations I simply missed the obvious: a
typo when moving the command from my test-table to the real-world-table.
Thnx a lot for your help. Now everything is working perfekt.
peter
---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match
