Re: [PATCH] Add array_reverse() function

From: Michael Paquier <michael(at)paquier(dot)xyz>
To: Пополитов Владлен <v(dot)popolitov(at)postgrespro(dot)ru>
Cc: Aleksander Alekseev <aleksander(at)timescale(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Ashutosh Bapat <ashutosh(dot)bapat(dot)oss(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Subject: Re: [PATCH] Add array_reverse() function
Date: 2024-10-31 02:10:09
Message-ID: ZyLnAZyxEuzD5KVo@paquier.xyz
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, Oct 30, 2024 at 10:11:20PM +0300, Пополитов Владлен wrote:
> Makes me wonder if we should have an utility function which would
> contain common code for array_shuffle() and array_reverse().
> Considering inconveniences such an approach caused in case of common
> code for text and bytea types [1] I choose to copy the code and modify
> it for the task.

We are talking about 20 lines copied over to reverse the order of
these elements that require their own inner for the element lookups
and manipulations. FWIW, I can live with this burden rather than
invent a routine that encapsulates both as this has also the
disadvantage of hiding more internals across more layers.

The abstraction with array_reverse_n() is unnecessary, but you have an
argument with the consistency and the shuffling inner routine.
Perhaps somebody will reuse that to invent a function that works on a
subset, where the comment on top array_reverse_n() about the type
caching still works. Anyway, no objections to what the patch defines
and does.

So it looks rather OK seen from here, as you are proposing.
--
Michael

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message vignesh C 2024-10-31 02:13:28 Re: Pgoutput not capturing the generated columns
Previous Message Noah Misch 2024-10-31 01:39:24 Re: Inval reliability, especially for inplace updates