[PATCH] Rename trim_array() for consistency with the rest of array_* functions
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
Attachments:
v1-0001-Rename-trim_array-to-array_trim.patchapplication/octet-stream; name=v1-0001-Rename-trim_array-to-array_trim.patchDownload+20-16
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