Re: POC: converting Lists into arrays - Mailing list pgsql-hackers

From David Rowley
Subject Re: POC: converting Lists into arrays
Date
Msg-id CAKJS1f_0nc8gk_6bLxQKsFt5os3UCk2MNsNcpva6LJoSoqFm=w@mail.gmail.com
Whole thread Raw
In response to Re: POC: converting Lists into arrays  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: POC: converting Lists into arrays  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Tue, 16 Jul 2019 at 07:49, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> A possibly controversial point is that I made list_qsort() sort the
> given list in-place, rather than building a new list as it has
> historically.  For every single one of the existing and new callers,
> copying the input list is wasteful, because they were just leaking
> the input list anyway.  But perhaps somebody feels that we should
> preserve the "const input" property?  I thought that changing the
> function to return void, as done here, might be a good idea to
> ensure that callers notice its API changed --- otherwise they'd
> only get a warning about incompatible signature of the passed
> function pointer, which they might not notice; in fact I'm not
> totally sure all compilers would even give such a warning.
>
> If there's not complaints about that, I'm just going to go ahead
> and push this --- it seems simple enough to not need much review.

The only thoughts I have so far here are that it's a shame that the
function got called list_qsort() and not just list_sort().  I don't
see why callers need to know anything about the sort algorithm that's
being used.

If we're going to break compatibility for this, should we rename the
function too?

-- 
 David Rowley                   http://www.2ndQuadrant.com/
 PostgreSQL Development, 24x7 Support, Training & Services



pgsql-hackers by date:

Previous
From: Amit Langote
Date:
Subject: Re: Change ereport level for QueuePartitionConstraintValidation
Next
From: Tom Lane
Date:
Subject: Re: POC: converting Lists into arrays