Leonardo F wrote: >> Yeah, I think you could do that, I agree it feels better that way. >> You'll still need new copytup and comparetup functions, though, to deal >> with HeapTupleHeaders instead of MinimalTuples, or modify the existing >> ones to handle both. > > You meant HeapTuple, not HeapTupleHeaders, right?
No, I did mean HeapTupleHeader. MinimalTuple struct is cut-down version HeapTupleHeader, while HeapTuple is structure that holds a pointer to HeapTupleHeader + some extra information. SortTuple takes the role of HeapTUple in tuplesort.c. A bit confusing, yes. That said, I didn't really look closely, maybe I'm missing something and HeapTuple is in fact the right struct to pass around. >> And some way to indicate that you want to preserve >> the visibility information when you create the tuplesort, maybe a new >> parameter to tuplesort_begin_heap(). > > I guess that using Gregory Stark's patch there's no need for it, since it uses > HeapTuples, right? Hmm, you still need to set different comparison function in Tuplesortstate->comparetup, so you'll still need a separate begin() function too, or a flag to the existing one. > A patch that: > > 1) uses always the old CLUSTER method for non-btree indexes and for > expression indexes > 2) add a whole set of new functions to tuplesort (as in Gregory Stark's patch) > > would be rejected "for sure"? Or can be thought as a "better than nothing, > works in 90% cases" patch? I'm fine with 1), though I wish we didn't have to add all that boilerplate code 2). I guess it's not a show-stopper. -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers