Re: POC: converting Lists into arrays
Tom Lane <tgl@sss.pgh.pa.us>
Robert Haas <robertmhaas@gmail.com> writes: > On Tue, Jul 16, 2019 at 10:44 AM Tom Lane <tgl@sss.pgh.pa.us> wrote: >> OK, I'm outvoted, will do it that way. > I cast my vote in the other direction i.e. for sticking with qsort. Didn't see this until after pushing a commit that uses "list_sort". While composing that commit message another argument occurred to me, which is that renaming makes it absolutely sure that any external callers will notice they have an API change to deal with, no matter how forgiving their compiler is. Also, if somebody really really doesn't want to cope with the change, they can now make their own version of list_qsort (stealing it out of 1cff1b95a) and the core code won't pose a conflict. So I'm good with "list_sort" at this point. regards, tom lane
Commits
-
Remove EState.es_range_table_array.
- 3c926587b592 13.0 landed
-
Rationalize use of list_concat + list_copy combinations.
- 5ee190f8ec37 13.0 landed
-
Cosmetic improvements in setup of planner's per-RTE arrays.
- 1661a4050593 13.0 landed
-
Make better use of the new List implementation in a couple of places
- efdcca55a3df 13.0 landed
-
Fix sepgsql test results for commit d97b714a2.
- 82c8a3c52adf 13.0 landed
-
Avoid using lcons and list_delete_first where it's easy to do so.
- d97b714a2199 13.0 landed
-
Remove lappend_cell...() family of List functions.
- c245776906b0 13.0 landed
-
Clean up some ad-hoc code for sorting and de-duplicating Lists.
- 2f5b8eb5a28b 13.0 landed
-
Redesign the API for list sorting (list_qsort becomes list_sort).
- 569ed7f48312 13.0 landed
-
Remove dead code.
- 4c3d05d875dd 13.0 landed
-
Represent Lists as expansible arrays, not chains of cons-cells.
- 1cff1b95ab6d 13.0 landed
-
Standardize some more loops that chase down parallel lists.
- c94fb8e8acc0 12.0 landed
-
Reimplement the linked list data structure used throughout the backend.
- d0b4399d81f3 8.0.0 cited