Aleksander Alekseev <a.aleks...@postgrespro.ru> writes: >> Can you explain use case where you need it?
> ... Or maybe you have different objects, e.g. IndexScanDesc's, that should > iterate over some tree's independently somewhere in indexam.c > procedures. Exact order may depend on user's query so you don't even > control it. It seems clear to me that the existing arrangement is hazardous for any RBTree that hasn't got exactly one consumer. I think Aleksander's plan to decouple the iteration state is probably a good one (NB: I've not read the patch, so this is not an endorsement of details). I'd go so far as to say that we should remove the old API as being dangerous, rather than preserve it on backwards-compatibility grounds. We make bigger changes than that in internal APIs all the time. Having said that, though: if the iteration state is not part of the object, it's not very clear whether we can behave sanely if someone changes the tree while an iteration is open. It will need careful thought as to what sort of guarantees we can make about that. If it's too weak, then a separated-state version would have enough hazards of its own that it's not necessarily any safer. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers