On Thu, Oct 24, 2024 at 8:27 AM Aleksander Alekseev < aleksan...@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.
