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 st
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 tha
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 t
Em ter., 29 de out. de 2024 às 09:01, Aleksander Alekseev <
aleksan...@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
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
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 except
