Thread: Re: [PATCH] Rename trim_array() for consistency with the rest of array_* functions
Re: [PATCH] Rename trim_array() for consistency with the rest of array_* functions
From
Vik Fearing
Date:
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
Re: [PATCH] Rename trim_array() for consistency with the rest of array_* functions
From
Aleksander Alekseev
Date:
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
Re: [PATCH] Rename trim_array() for consistency with the rest of array_* functions
From
Aleksander Alekseev
Date:
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