Re: [Patch] RBTree iteration interface improvement
От | Robert Haas |
---|---|
Тема | Re: [Patch] RBTree iteration interface improvement |
Дата | |
Msg-id | CA+TgmoZsZwyprjC-c0-QFNcGjUfpEVjN-gE3+Ee0sT71SrLn4A@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: [Patch] RBTree iteration interface improvement (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: [Patch] RBTree iteration interface improvement
|
Список | pgsql-hackers |
On Thu, Jul 28, 2016 at 1:57 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > 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. +1 to all of that. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
В списке pgsql-hackers по дате отправления: