"David G. Johnston" <david.g.johnston@gmail.com> writes:
> 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.
Oh! I had not actually looked at the details of what was being
proposed here. I imagined "array_sort(anyarray)" and the sort would
use the default sort order for the array's element type. This
business with a textual representation of a sort clause seems like
over-engineering ... except that it's also under-engineered, because
the parsing is lame and incomplete. (No USING option, and the fact
that collation comes from somewhere else seems impossibly confusing.)
Let's drop that. As already noted, if you need a non-default sort
order you can build what you want with a sub-select. The ambition
here should be to make easy cases easy.
regards, tom lane
