> Ok, committed.
>
> - Heikki
Thanks a lot for committing this patch and also for your contribution to
it!
--
Best regards,
Aleksander Alekseev
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql
On 08/26/2016 04:07 PM, Aleksander Alekseev wrote:
Another unrelated change in this patch is the addition of
rb_rightmost(). It's not used for anything, so I'm not sure what the
point is. Then again, there don't seem to be any callers of
rb_leftmost() either.
It's just something I needed in tes
Hello, Heikki.
Thank you for your attention to this patch!
> This also seems to change the API so that instead of a single
> rb_begin_iterate()+rb_iterate() pair, there is a separate begin and
> iterate function for each traversal order. That seems like an unrelated
> change. Was there a parti
On 08/22/2016 01:00 PM, Aleksander Alekseev wrote:
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
> > 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
> > 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 w
On Thu, Jul 28, 2016 at 1:57 PM, Tom Lane wrote:
> Aleksander Alekseev 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 orde
Aleksander Alekseev 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
> Can you explain use case where you need it?
Sure. You can consider RBTree as a container that always keeps its
elements in sorted order. Now imagine you would like to write a code
like this:
```
/* iterate over items in sorted order */
while(item1 = left_right_walk(tree))
{
/* another itera
On Wed, Jul 27, 2016 at 7:56 PM, Aleksander Alekseev
wrote:
> Hello
>
> While working on some new feature for PostgreSQL (which is still in
> development and is irrelevant in this context) I noticed that current
> RBTree implementation interface is following:
>
> ```
> extern void rb_begin_iterate
And as always, I didn't re-check a patch before sending it :) Here is a
corrected version without any fprintf's.
--
Best regards,
Aleksander Alekseev
diff --git a/src/backend/access/gin/ginbulk.c b/src/backend/access/gin/ginbulk.c
index d6422ea..eac76c4 100644
--- a/src/backend/access/gin/ginbulk
Hello
While working on some new feature for PostgreSQL (which is still in
development and is irrelevant in this context) I noticed that current
RBTree implementation interface is following:
```
extern void rb_begin_iterate(RBTree *rb, RBOrderControl ctrl);
extern RBNode *rb_iterate(RBTree *rb);
`
12 matches
Mail list logo
