Thread: TRIM_ARRAY
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 that this won't give you the first n elements if your lower bound is not 1. My justification for this is 1) non-standard lower bounds are so rare in the wild that 2) people using them can just not use this function. The alternative is to go through the unnest dance (or write it in C) which defeats inlining. Patch attached. -- Vik Fearing
Attachment
On Tue, 16 Feb 2021 at 12:54, Vik Fearing <vik@postgresfriends.org> 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 interesting case that I decided to handle by explaining it in the
docs is that this won't give you the first n elements if your lower
bound is not 1. My justification for this is 1) non-standard lower
bounds are so rare in the wild that 2) people using them can just not
use this function. The alternative is to go through the unnest dance
(or write it in C) which defeats inlining.
I don't recall ever seeing non-default lower bounds, so I actually think it's OK to just rule out that scenario, but why not something like this:
($1)[:array_lower ($1, 1) + $2 - 1]
Note that I've used the 9.6 feature that allows omitting the lower bound.
On 2/16/21 7:32 PM, Isaac Morland wrote: > On Tue, 16 Feb 2021 at 12:54, Vik Fearing <vik@postgresfriends.org> 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 interesting case that I decided to handle by explaining it in the >> docs is that this won't give you the first n elements if your lower >> bound is not 1. My justification for this is 1) non-standard lower >> bounds are so rare in the wild that 2) people using them can just not >> use this function. The alternative is to go through the unnest dance >> (or write it in C) which defeats inlining. >> > > I don't recall ever seeing non-default lower bounds, so I actually think > it's OK to just rule out that scenario, but why not something like this: > > ($1)[:array_lower ($1, 1) + $2 - 1] I'm kind of embarrassed that I didn't think about doing that; it is a much better solution. You lose the non-standard bounds but I don't think there is any way besides C to keep the lower bound regardless of how you trim it. V2 attached. -- Vik Fearing
Attachment
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 <vik@postgresfriends.org> 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 interesting case that I decided to handle by explaining it in the >>> docs is that this won't give you the first n elements if your lower >>> bound is not 1. My justification for this is 1) non-standard lower >>> bounds are so rare in the wild that 2) people using them can just not >>> use this function. The alternative is to go through the unnest dance >>> (or write it in C) which defeats inlining. >>> >> >> I don't recall ever seeing non-default lower bounds, so I actually think >> it's OK to just rule out that scenario, but why not something like this: >> >> ($1)[:array_lower ($1, 1) + $2 - 1] > > I'm kind of embarrassed that I didn't think about doing that; it is a > much better solution. You lose the non-standard bounds but I don't > think there is any way besides C to keep the lower bound regardless of > how you trim it. I've made a bit of a mess out of this, but I partly blame the standard which is very unclear. It actually describes trimming the right n elements instead of the left n like I've done here. I'll be back later with a better patch that does what it's actually supposed to. -- Vik Fearing