On Thu, Feb 8, 2024 at 12:01 PM Mats Kindahl <m...@timescale.com> wrote:
> On Wed, Feb 7, 2024 at 9:56 PM Nathan Bossart <nathandboss...@gmail.com> > wrote: > >> On Wed, Feb 07, 2024 at 08:46:56PM +0200, Heikki Linnakangas wrote: >> > Doesn't hurt to fix the comparison functions, and +1 on using the same >> > pattern everywhere. >> >> I attached a new version of the patch with some small adjustments. I >> haven't looked through all in-tree qsort() comparators to see if any >> others >> need to be adjusted, but we should definitely do so as part of this >> thread. >> Mats, are you able to do this? >> > > Sure, I checked them and the only ones remaining are those using int16. > Shall I modify those as well? > Seems your additional patch dealt with at least one of the cases. > > >> > However, we use our qsort() with user-defined comparison functions, and >> we >> > cannot make any guarantees about what they might do. So we must ensure >> that >> > our qsort() doesn't overflow, no matter what the comparison function >> does. >> > >> > Looking at our ST_SORT(), it seems safe to me. >> >> Cool. >> >> -- >> Nathan Bossart >> Amazon Web Services: https://aws.amazon.com >> >
