Aleksander Alekseev <a.alekseev@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
