Re: general purpose array_sort
Tom Lane <tgl@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
To: "David G. Johnston" <david.g.johnston@gmail.com>
Cc: Aleksander Alekseev <aleksander@timescale.com>,
PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>,
Junwang Zhao <zhjwpku@gmail.com>,
jian he <jian.universality@gmail.com>,
Amit Langote <amitlangote09@gmail.com>,
"andreas@proxel.se" <andreas@proxel.se>,
Robert Haas <robertmhaas@gmail.com>
Date: 2024-10-24T16:06:32Z
Lists: pgsql-hackers
"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
Commits
-
Introduce a SQL-callable function array_sort(anyarray).
- 6c12ae09f5a5 18.0 landed
-
Fix ARRAY_SUBLINK and ARRAY[] for int2vector and oidvector input.
- 4618045bee4a 18.0 cited
-
Re-implement the ereport() macro using __VA_ARGS__.
- e3a87b4991cc 13.0 cited