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
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 |