| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
| Cc: | David Steele <david(at)pgmasters(dot)net>, David Rowley <david(dot)rowley(at)2ndquadrant(dot)com>, Jesper Pedersen <jesper(dot)pedersen(at)redhat(dot)com>, Andres Freund <andres(at)anarazel(dot)de>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: POC: converting Lists into arrays |
| Date: | 2019-07-16 16:08:53 |
| Message-ID: | 6023.1563293333@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> On Tue, Jul 16, 2019 at 10:44 AM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Robert Haas | 2019-07-16 16:14:30 | Re: POC: Cleaning up orphaned files using undo logs |
| Previous Message | Peter Geoghegan | 2019-07-16 16:07:37 | Re: POC: converting Lists into arrays |