Re: Sort functions with specialized comparators

From: John Naylor <johncnaylorls(at)gmail(dot)com>
To: "Andrey M(dot) Borodin" <x4mmm(at)yandex-team(dot)ru>
Cc: David Rowley <dgrowleyml(at)gmail(dot)com>, Антуан Виолин <violin(dot)antuan(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Sort functions with specialized comparators
Date: 2025-01-04 05:24:33
Message-ID: CANWCAZaDxgn7pa6=dy4L-2pQ9OPB2dcqP-O+mvpDCeH2Kk7pNA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Sat, Dec 21, 2024 at 12:16 AM Andrey M. Borodin <x4mmm(at)yandex-team(dot)ru> wrote:
>
>
>
> > On 16 Dec 2024, at 14:02, John Naylor <johncnaylorls(at)gmail(dot)com> wrote:
> >
> > Sorry, I forgot this part earlier. Yes, let's have the private function.
>
> PFA v6.

v6-0001:

+static int
+unique_cmp(const void *a, const void *b)
+{
+ int32 aval = *((const int32 *) a);
+ int32 bval = *((const int32 *) b);
+
+ return pg_cmp_s32(aval, bval);
+}

I'm not sure it makes sense to create a whole new function for this,
when the same patch removed:

-int
-compASC(const void *a, const void *b)
-{
- return pg_cmp_s32(*(const int32 *) a, *(const int32 *) b);
-}

...which in effect the exact same thing.

Otherwise seems close to committable.

v6-0002: Seems like a good idea to be more consistent, but I admit I'm
not much a fan of little indirection macros like this. It makes the
code less readable in my view.

v6-0003: I didn't feel like digging further. It's interesting that
inner_int_inter() takes care to detect the zero-length case and free
the old array to avoid resizing.

--
John Naylor
Amazon Web Services

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Pavel Stehule 2025-01-04 05:36:56 Re: Re: proposal: schema variables
Previous Message Tatsuo Ishii 2025-01-04 04:54:39 Re: Proposal: add new API to stringinfo