Re: general purpose array_sort
| От | David G. Johnston |
|---|---|
| Тема | Re: general purpose array_sort |
| Дата | |
| Msg-id | CAKFQuwbrXFUgs8R1F2wsAG_V5e2qqU0FUnuLuLjrYP9VSUZFTg@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: general purpose array_sort (Aleksander Alekseev <aleksander@timescale.com>) |
| Ответы |
Re: general purpose array_sort
|
| Список | pgsql-hackers |
On Thu, Oct 24, 2024 at 8:27 AM Aleksander Alekseev <aleksander@timescale.com> wrote:
Just making an observation / thinking out loud that the requirement to
support everything ORDER BY handles / supports (and will handle /
support?) might make this function impractical to maintain.
Particularly, does the function really need to support dir => asc |
desc | asc nulls first | etc... ? Maybe array_sort() + array_reverse(
array_sort() ) will handle most of the practical cases? I don't know.
[1]: https://commitfest.postgresql.org/50/5314/
Composing function calls here seems quite undesirable from a performance standpoint, but maybe I over-estimate the cost of exploding-manipulating-freezing an array datum. Also, while I'm not in a good position to judge the challenge of implementing the sort parameters I would rather have them than not since the order by API has them (plus performance). I also, maybe unreasonably, believe that our extensible type system has already limited the maintenance burden.
David J.
В списке pgsql-hackers по дате отправления: