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
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
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
(les
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
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
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
Nathan Bossart writes:
> On Mon, Jul 25, 2022 at 04:40:51PM +0200, Martin Kalcher wrote:
>> +SELECT trim_array(ARRAY[]::int[], 1); -- fail
>> +ERROR: number of elements to trim must be between 0 and 0
> Can we improve the error message? Maybe it should look something
On Mon, Jul 25, 2022 at 04:40:51PM +0200, Martin Kalcher wrote:
> +SELECT trim_array(ARRAY[]::int[], 1); -- fail
> +ERROR: number of elements to trim must be between 0 and 0
Can we improve the error message? Maybe it should look something like
ERROR: number of elements to trim m
Hi,
while working on something else i encountered a bug in the trim_array()
function. The bounds check fails for empty arrays without any
dimensions. It reads the size of the non existing first dimension to
determine the arrays length.
select trim_array('{}':
On 3/3/21 10:47 PM, Tom Lane wrote:
>
> I had the same problem as Dian of the func.sgml hunk winding up in
> the wrong place. I think this is practically inevitable unless the
> submitter uses more than 3 lines of context for the diff, because
> otherwise the context is just boilerplate that look
Vik Fearing writes:
> On 3/2/21 1:02 AM, Dian M Fay wrote:
>> I'd thought that checking v and returning null instead of raising the
>> error would be more friendly, should it be possible to pass an untyped
>> null accidentally instead of on purpose, and I couldn't rule that out.
> As Tom said, th
On 3/2/21 1:02 AM, Dian M Fay wrote:
> On Mon Mar 1, 2021 at 6:53 PM EST, Vik Fearing wrote:
>>> This basically does what it says, and the code looks good. The
>>> documentation is out of alphabetical order (trim_array should appear
>>> under cardinality rather
On Mon Mar 1, 2021 at 6:53 PM EST, Vik Fearing wrote:
> > This basically does what it says, and the code looks good. The
> > documentation is out of alphabetical order (trim_array should appear
> > under cardinality rather than over)) but good otherwise.
>
> Hmm. It appears
Dian Fay writes:
> This basically does what it says, and the code looks good. The
> documentation is out of alphabetical order (trim_array should appear
> under cardinality rather than over)) but good otherwise. I was able to
> "break" the function with an untyped n
Thank you for looking at my patch!
> This basically does what it says, and the code looks good. The
> documentation is out of alphabetical order (trim_array should appear
> under cardinality rather than over)) but good otherwise.
Hmm. It appears between cardinality and unnest in the
. The
documentation is out of alphabetical order (trim_array should appear
under cardinality rather than over)) but good otherwise. I was able to
"break" the function with an untyped null in psql:
select trim_array(null, 2);
ERROR: could not determine polymorphic type because input has ty
on is now in C.
--
Vik Fearing
>From 1fb4e07651053ab20b2f853e5ec753aad5002782 Mon Sep 17 00:00:00 2001
From: Vik Fearing
Date: Tue, 16 Feb 2021 18:38:24 +0100
Subject: [PATCH] implement trim_array
---
doc/src/sgml/func.sgml | 18
src/backend/catalog/sql_features.txt | 2 +-
s
On 2/16/21 11:38 PM, Vik Fearing wrote:
> On 2/16/21 7:32 PM, Isaac Morland wrote:
>> On Tue, 16 Feb 2021 at 12:54, Vik Fearing wrote:
>>
>>> The SQL standard defines a function called TRIM_ARRAY that surprisingly
>>> has syntax that looks like a function!
On 2/16/21 7:32 PM, Isaac Morland wrote:
> On Tue, 16 Feb 2021 at 12:54, Vik Fearing wrote:
>
>> The SQL standard defines a function called TRIM_ARRAY that surprisingly
>> has syntax that looks like a function! So I implemented it using a thin
>> wrapper around our ar
On Tue, 16 Feb 2021 at 12:54, Vik Fearing wrote:
> The SQL standard defines a function called TRIM_ARRAY that surprisingly
> has syntax that looks like a function! So I implemented it using a thin
> wrapper around our array slice syntax. It is literally just ($1)[1:$2].
>
> An i
The SQL standard defines a function called TRIM_ARRAY that surprisingly
has syntax that looks like a function! So I implemented it using a thin
wrapper around our array slice syntax. It is literally just ($1)[1:$2].
An interesting case that I decided to handle by explaining it in the
docs is
21 matches
Mail list logo
