[PATCH] Rename trim_array() for consistency with the rest of array_* functions
Hackorum builds and tests every patch posted to the lists, not only commitfest submissions. This is Hackorum's own CI rather than the PostgreSQL project's, and it is still under testing - please report anything that looks wrong.
You can run a PostgreSQL built from this patch straight from Docker, with no checkout and no build:
docker run --rm -p 5432:5432 ghcr.io/hackorum-dev/postgres-patch:t50470psql -h localhost -U postgresBuilt from patchset v1 (message #1), July 27, 2026 at 11:08 AM.
Every patchset is also pushed to a branch of our PostgreSQL fork, so you can check out the same tree CI built. Without a PostgreSQL checkout:
git clone --branch t50470_1 https://github.com/hackorum-dev/postgres.gitIn a checkout you already have, add the fork once:
git remote add hackorum https://github.com/hackorum-dev/postgres.gitthen, for this patchset and every later one:
git fetch hackorum t50470_1 && git checkout t50470_1Patchset v1 (message #1) is on t50470_1
Hi hackers,
Currently most of the functions dealing with arrays ( except for
unnest() and cardinality() ) start with `array_` prefix [1]https://www.postgresql.org/docs/current/functions-array.html -
array_length(), array_fill(), etc. Also this is how we name the new
functions, e.g. recently proposed array_sort() [2]https://commitfest.postgresql.org/50/5277/ and array_reverse()
[3]: https://commitfest.postgresql.org/50/5314/
somewhat misleading. For instance, it is not show in the output of:
```
\df array_*
```
The proposed patch renames trim_array() to array_trim(). The old
function is kept for backward compatibility but is marked as
deprecated and is left undocumented. It can be removed in 10 years
from now or so. To my knowledge this is how we typically deprecate old
functions and operators.
Thoughts?
[1]: https://www.postgresql.org/docs/current/functions-array.html
[2]: https://commitfest.postgresql.org/50/5277/
[3]: https://commitfest.postgresql.org/50/5314/
--
Best regards,
Aleksander Alekseev
On 29/10/2024 13:01, Aleksander Alekseev wrote:
Hi hackers,
Currently most of the functions dealing with arrays ( except for
unnest() and cardinality() ) start with `array_` prefix [1] -
array_length(), array_fill(), etc. Also this is how we name the new
functions, e.g. recently proposed array_sort() [2] and array_reverse()
[3]. The only exception from this rule is trim_array() which might be
somewhat misleading. For instance, it is not show in the output of:```
\df array_*
```The proposed patch renames trim_array() to array_trim(). The old
function is kept for backward compatibility but is marked as
deprecated and is left undocumented. It can be removed in 10 years
from now or so. To my knowledge this is how we typically deprecate old
functions and operators.Thoughts?
While unfortunately named, we cannot deprecate TRIM_ARRAY() because it
is mandated by the standard.
--
Vik Fearing
Em ter., 29 de out. de 2024 às 09:01, Aleksander Alekseev <
aleksander@timescale.com> escreveu:
The proposed patch renames trim_array() to array_trim().
That Array Functions list on func.sgml is an ordered list, so the right
place for it should be before array_upper, right ?
regards
Marcos
Hi Vik,
While unfortunately named, we cannot deprecate TRIM_ARRAY() because it
is mandated by the standard.
I didn't know that, thanks.
Still PostgreSQL doesn't follow the standard precisely in more than
one respect. Perhaps we should add array_trim() and keep both? Or
(less likely) remove trim_array() and document this deviation from the
standard? Or at least document why it's named this way.
What do you think?
--
Best regards,
Aleksander Alekseev
On Tue, Oct 29, 2024 at 03:23:15PM +0300, Aleksander Alekseev wrote:
While unfortunately named, we cannot deprecate TRIM_ARRAY() because it
is mandated by the standard.I didn't know that, thanks.
Wow. Neither did I.
Still PostgreSQL doesn't follow the standard precisely in more than
one respect. Perhaps we should add array_trim() and keep both? Or
(less likely) remove trim_array() and document this deviation from the
standard? Or at least document why it's named this way.
I suspect that it is not the only function in this case, and that we
don't document that it is in the standard. I would suggest to let
things the way they are on HEAD and withdraw the patch.
--
Michael
Hi Michael,
On Tue, Oct 29, 2024 at 03:23:15PM +0300, Aleksander Alekseev wrote:
While unfortunately named, we cannot deprecate TRIM_ARRAY() because it
is mandated by the standard.I didn't know that, thanks.
Wow. Neither did I.
Still PostgreSQL doesn't follow the standard precisely in more than
one respect. Perhaps we should add array_trim() and keep both? Or
(less likely) remove trim_array() and document this deviation from the
standard? Or at least document why it's named this way.I suspect that it is not the only function in this case, and that we
don't document that it is in the standard. I would suggest to let
things the way they are on HEAD and withdraw the patch.
Thanks for your feedback. The patch is withdrawn.
--
Best regards,
Aleksander Alekseev