> > 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.
>
> +1 to all of that.
>
The old API assumes that tree doesn't change during iteration. And it
doesn't do any checks about this. The new API behaves the same way. In
this sense patch at least doesn't make anything worse.
> 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.
Glad to hear it! I would like to propose a patch that removes the old
API. I have a few questions though.
Would you like it to be a separate patch, or all-in-one patch is fine
in this case? I also would like to include unit/property-based tests in
this (these) patch (patches). However as I understand there are
currently no unit tests in PostgreSQL at all, only integration/system
tests. Any advice how to do it better?
--
Best regards,
Aleksander Alekseev