Re: [Patch] RBTree iteration interface improvement
От | Tom Lane |
---|---|
Тема | Re: [Patch] RBTree iteration interface improvement |
Дата | |
Msg-id | 24680.1469728679@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: [Patch] RBTree iteration interface improvement (Aleksander Alekseev <a.alekseev@postgrespro.ru>) |
Ответы |
Re: [Patch] RBTree iteration interface improvement
|
Список | pgsql-hackers |
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
В списке pgsql-hackers по дате отправления: