On Thu, Jul 28, 2016 at 1:57 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > 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.
+1 to all of that. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
