Thread: Some questions about the array.

We were some of the issues associated with the behavior of arrays.
1. We would like to implement arrays negative indices (from the end) like in 
Python or Ruby: arr[-2]  or arr[1: -1] 
but as an array can be indexed in the negative area so it probably can not be 
done.
2. We would like to add the ability be omitted boundaries in the slice.
Example: arr[2:] or arr[:2]. But there was a problem with the update of an 
empty array:
arr[1:][1:] = {1,2,3,4,5,6} can be interpreted as 
arr[1:3][1:2] or arr[1:2] [1:3] or [1:1], [1:6]

What is the history of the emergence of such arrays? Maybe something can be 
improved?

P.S. I would like List datatype as in Python.  Is there any fundamental 
objections? Or we just did not have the time and enthusiasm before?
The current implementation I would call vectors or matrices but not arrays. 
IMHO


-- 
YUriy Zhuravlev
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company

On 10/09/2015 08:02 AM, YUriy Zhuravlev wrote:
> We were some of the issues associated with the behavior of arrays.
> 1. We would like to implement arrays negative indices (from the end) like in
> Python or Ruby: arr[-2]  or arr[1: -1]
> but as an array can be indexed in the negative area so it probably can not be
> done.
> 2. We would like to add the ability be omitted boundaries in the slice.
> Example: arr[2:] or arr[:2]. But there was a problem with the update of an
> empty array:
> arr[1:][1:] = {1,2,3,4,5,6} can be interpreted as
> arr[1:3][1:2] or arr[1:2] [1:3] or [1:1], [1:6]
>
> What is the history of the emergence of such arrays? Maybe something can be
> improved?
>
> P.S. I would like List datatype as in Python.  Is there any fundamental
> objections? Or we just did not have the time and enthusiasm before?
> The current implementation I would call vectors or matrices but not arrays.
> IMHO
>
>

The name array is now far too baked in to change it.

jsonb and json arrays have many of the characteristics you seem to want. 
They are always 0-based and negative indexes count from the end. They 
also don't have to be regular, unlike our native arrays.

cheers

andrew

On Fri, Oct 9, 2015 at 8:02 AM, YUriy Zhuravlev
<u.zhuravlev@postgrespro.ru> wrote:
> We were some of the issues associated with the behavior of arrays.
> 1. We would like to implement arrays negative indices (from the end) like in
> Python or Ruby: arr[-2]  or arr[1: -1]
> but as an array can be indexed in the negative area so it probably can not be
> done.

That seems like a complete non-starter because it would break backward
compatibility.  Our array implementation allows negative indexes:

rhaas=# select ('[-1:4]={3,1,4,1,5,9}'::int[])[-1];int4
------   3
(1 row)

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

Hello again.
I attached simple patch for omitted boundaries in the slice.
This will simplify the writing of SQL. Instead:
select arr[2:array_upper(arr, 1)];
you can write:
select arr[2:];

simple and elegant.
Omitted boundaries is prohibited in UPDATE.

Thanks.
--
YUriy Zhuravlev
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company

Hello hackers.
There are comments to my patch? Maybe I should create a separate thread?
Thanks.
-- 
YUriy Zhuravlev
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company

On Thu, Nov 5, 2015 at 9:57 AM, YUriy Zhuravlev
<u.zhuravlev@postgrespro.ru> wrote:
> Hello hackers.
> There are comments to my patch? Maybe I should create a separate thread?
> Thanks.

You should add this on commitfest.postgresql.org.

I think the first question that needs to be answered is "do we want
this?".  I'm sure I know your answer, but what do other people think?

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

On 6 November 2015 at 12:45, Robert Haas <robertmhaas@gmail.com> wrote:
> On Thu, Nov 5, 2015 at 9:57 AM, YUriy Zhuravlev
> <u.zhuravlev@postgrespro.ru> wrote:
>> Hello hackers.
>> There are comments to my patch? Maybe I should create a separate thread?
>> Thanks.
>
> You should add this on commitfest.postgresql.org.
>
> I think the first question that needs to be answered is "do we want
> this?".  I'm sure I know your answer, but what do other people think?

Omitted bounds are common in other languages and would be handy. I
don't think they'd cause any issues with multi-dimensional arrays or
variable start-pos arrays.

I'd love negative indexes, but the variable-array-start (mis)feature
means we can't have those. I wouldn't shed a tear if
variable-start-position arrays were deprecated and removed, but that's
a multi-year process, and I'm not convinced negative indexes justify
it even though the moveable array start pos feature seems little-used.

Since the start-pos is recorded in the array, I wonder if it's worth
supporting negative indexing for arrays with the default 1-indexed
element numbering, and just ERRORing for others. Does anyone really
use anything else?

-- Craig Ringer                   http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training & Services

On 6 November 2015 at 12:45, Robert Haas <robertmhaas@gmail.com> wrote:
> On Thu, Nov 5, 2015 at 9:57 AM, YUriy Zhuravlev
> <u.zhuravlev@postgrespro.ru> wrote:
>> Hello hackers.
>> There are comments to my patch? Maybe I should create a separate thread?
>> Thanks.
>
> You should add this on commitfest.postgresql.org.
>
> I think the first question that needs to be answered is "do we want
> this?".  I'm sure I know your answer, but what do other people think?

Omitted bounds are common in other languages and would be handy. I
don't think they'd cause any issues with multi-dimensional arrays or
variable start-pos arrays.

I'd love negative indexes, but the variable-array-start (mis)feature
means we can't have those. I wouldn't shed a tear if
variable-start-position arrays were deprecated and removed, but that's
a multi-year process, and I'm not convinced negative indexes justify
it even though the moveable array start pos feature seems little-used.

Since the start-pos is recorded in the array, I wonder if it's worth
supporting negative indexing for arrays with the default 1-indexed
element numbering, and just ERRORing for others. Does anyone really
use anything else?

On Thursday 05 November 2015 22:33:37 you wrote:
> Would something like array[1:~1] as a syntax be acceptable to denote
> backward counting?
Very interesting idea! I could implement it. I just need to check for side 
effects.

-- 
YUriy Zhuravlev
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company

On Thursday 05 November 2015 23:45:53 you wrote:
> On Thu, Nov 5, 2015 at 9:57 AM, YUriy Zhuravlev
> 
> <u.zhuravlev@postgrespro.ru> wrote:
> > Hello hackers.
> > There are comments to my patch? Maybe I should create a separate thread?
> > Thanks.
> 
> You should add this on commitfest.postgresql.org.
I created a couple of weeks ago:
https://commitfest.postgresql.org/7/397/

> 
> I'm sure I know your answer, but what do other people think?
I wonder the same thing.

Thanks.
-- 
YUriy Zhuravlev
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company

On 11/5/15 10:55 PM, Craig Ringer wrote:
> Omitted bounds are common in other languages and would be handy. I
> don't think they'd cause any issues with multi-dimensional arrays or
> variable start-pos arrays.

+1

> I'd love negative indexes, but the variable-array-start (mis)feature
> means we can't have those. I wouldn't shed a tear if
> variable-start-position arrays were deprecated and removed, but that's
> a multi-year process, and I'm not convinced negative indexes justify
> it even though the moveable array start pos feature seems little-used.

I'm all for ditching variable start, full stop.

> Since the start-pos is recorded in the array, I wonder if it's worth
> supporting negative indexing for arrays with the default 1-indexed
> element numbering, and just ERRORing for others. Does anyone really
> use anything else?

I'd prefer that over using something like ~.
-- 
Jim Nasby, Data Architect, Blue Treble Consulting, Austin TX
Experts in Analytics, Data Architecture and PostgreSQL
Data in Trouble? Get it in Treble! http://BlueTreble.com

On Fri, Nov 6, 2015 at 9:44 PM, Jim Nasby <Jim.Nasby@bluetreble.com> wrote:
>> Since the start-pos is recorded in the array, I wonder if it's worth
>> supporting negative indexing for arrays with the default 1-indexed
>> element numbering, and just ERRORing for others. Does anyone really
>> use anything else?
>
> I'd prefer that over using something like ~.

I'm not necessarily objecting to that, but it's not impossible that it
could break something for some existing user.  We can decide not to
care about that, though.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

On Sunday 08 November 2015 16:49:20 you wrote:
> I'm not necessarily objecting to that, but it's not impossible that it
> could break something for some existing user.  We can decide not to
> care about that, though.

We had an idea. You can use ~ to convert the index to the array which always 
starts with 0. Then we can use negative indexes, and you can always find the 
beginning of the array.
Example:
we have array [-3:3]={1,2,3,4,5,6,7}
array[~0] == 1
array[~-1] == 7
array[~2:~-2] == {3,4,5,6}

What do you think?
-- 
YUriy Zhuravlev
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company

On Monday 09 November 2015 12:48:54 you wrote:
> I am sorry - it is looking pretty obscure. Really need this feature?

IMHO yes.
Now for write: array[~2:~-2] you need like:
array[array_lower(array, 1)+3: array_upper(array, 1)-2]

Worse when long names. Besides the extra functions calls.

Thanks.
-- 
YUriy Zhuravlev
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company

>From: pgsql-hackers-owner@postgresql.org [mailto:pgsql-hackers-owner@postgresql.org] On Behalf Of Pavel Stehule
>Sent: Montag, 9. November 2015 12:49
>To: YUriy Zhuravlev
>Cc: PostgreSQL Hackers
>Subject: Re: [HACKERS] Some questions about the array.
>
>
>
>2015-11-09 12:36 GMT+01:00 YUriy Zhuravlev <u.zhuravlev@postgrespro.ru>:
>On Sunday 08 November 2015 16:49:20 you wrote:
>> I'm not necessarily objecting to that, but it's not impossible that it
>> could break something for some existing user.  We can decide not to
>> care about that, though.
>
>We had an idea. You can use ~ to convert the index to the array which always
>starts with 0. Then we can use negative indexes, and you can always find the
>beginning of the array.
>Example:
>we have array [-3:3]={1,2,3,4,5,6,7}
>array[~0] == 1
>array[~-1] == 7
>array[~2:~-2] == {3,4,5,6}
>
>What do you think?

Hi,

~ is the bitwise NOT operator.
so array[~n:~m] has a current meaning. Not very useful though.
It would be better to choose another character.

my 2 pence,

Marc Mamin

On 11/9/15, YUriy Zhuravlev <u.zhuravlev@postgrespro.ru> wrote:
> On Monday 09 November 2015 12:48:54 you wrote:
>> I am sorry - it is looking pretty obscure. Really need this feature?
>
> IMHO yes.
> Now for write: array[~2:~-2] you need like:
> array[array_lower(array, 1)+3: array_upper(array, 1)-2]
>
> Worse when long names. Besides the extra functions calls.

You can write it as a separate function instead of changing current syntax.
Call would be like :
SELECT slice_abs('[-3:3]={1,2,3,4,5,6,7}'::int[], 2, -2)  == {3,4,5,6}
SELECT slice_abs('[-3:3]={1,2,3,4,5,6,7}'::int[], 2, NULL)  ==
{3,4,5,6,7}  -- omitting boundaries
-- 
Best regards,
Vitaly Burovoy

On Monday 09 November 2015 13:29:30 you wrote:
> It is ugly, but you can wrap it to function - so still I don't see any
> reason, why it is necessary
For example, I'm writing a lot of queries by hands...
This functionality is available in many languages and it's just convenient. Of 
course it is possible and without it, but why?

Thanks.
-- 
YUriy Zhuravlev
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company

On Monday 09 November 2015 04:33:28 you wrote:
> You can write it as a separate function instead of changing current syntax.
I do not think, because we have a multi-dimensional arrays.
And why we have [:] syntax now?
-- 
YUriy Zhuravlev
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company

On Monday 09 November 2015 13:50:20 Pavel Stehule wrote:
> New symbols increase a complexity of our code and our documentation.
> 
> If some functionality can be implemented via functions without performance
> impacts, we should not to create new operators or syntax - mainly for
> corner use cases.
> 
> Regards
> 
> Pavel

Ok we can use {:} instead [:] for zero array access.  
The function is the solution half.

-- 
YUriy Zhuravlev
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company

On Friday 06 November 2015 12:55:44 you wrote:
> Omitted bounds are common in other languages and would be handy. I
> don't think they'd cause any issues with multi-dimensional arrays or
> variable start-pos arrays.

And yet, what about my patch?
Discussions about ~ and{:} it seems optional.

Thanks.
-- 
YUriy Zhuravlev
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company

On Wednesday 11 November 2015 17:29:31 you wrote:
> In this case the syntax is major issue. Any language should not to have any
> possible feature on the world.

I am about omitted boundaries. It almost does not change the syntax and with 
nothing conflicts.

Thanks.
-- 
YUriy Zhuravlev
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company

YUriy Zhuravlev wrote:
> On Friday 06 November 2015 12:55:44 you wrote:
>> Omitted bounds are common in other languages and would be handy. I
>> don't think they'd cause any issues with multi-dimensional arrays or
>> variable start-pos arrays.
>
> And yet, what about my patch?

My vote: let us do it, mean, omitting bounds. It simplifies syntax in rather 
popular queries.


> Discussions about ~ and{:} it seems optional.
~ is allowed as unary operator and therefore such syntax will introduce 
incompatibily/ambiguity.


-- 
Teodor Sigaev                                   E-mail: teodor@sigaev.ru
  WWW: http://www.sigaev.ru/
 

Some comments about patch
1
Documentation isn't very informative
Outputs of
SELECT schedule[:][:] FROM sal_emp WHERE name = 'Bill'
and
SELECT schedule[:2][1:] FROM sal_emp WHERE name = 'Bill';
are the same. Suppose, it's better to have differs ones.

2
# create table xxx (a int[]);
# update xxx set a[2:] = '{1,2}';
UPDATE 0
# update xxx set a[2:] = '{1,2}';
ERROR:  cannot determine upper index for empty array
# update xxx set a[:2] = '{1,2}';
ERROR:  invalid input syntax for integer: "{1,2}"
# update xxx set a[:] = '{1,2}';
ERROR:  invalid input syntax for integer: "{1,2}"

Seems, error messages are too inconsistent. If you forbid omitting bound in 
assigment then if all cases error message should be the same or close.


YUriy Zhuravlev wrote:
> Hello again.
> I attached simple patch for omitted boundaries in the slice.
> This will simplify the writing of SQL. Instead:
> select arr[2:array_upper(arr, 1)];
> you can write:
> select arr[2:];
>
> simple and elegant.
> Omitted boundaries is prohibited in UPDATE.
>
> Thanks.
>
>
>
>

-- 
Teodor Sigaev                                   E-mail: teodor@sigaev.ru
  WWW: http://www.sigaev.ru/
 

The new version of the patch.

On Friday 27 November 2015 17:23:35 Teodor Sigaev wrote:
> 1
> Documentation isn't very informative
Added example with different results.

> 2
> Seems, error messages are too inconsistent. If you forbid omitting bound in
> assigment then if all cases error message should be the same or close.
Done.  Skipping lower boundary is no longer an error.

Thank you for your review.

--
YUriy Zhuravlev
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company

On Thu, Nov 26, 2015 at 6:08 AM, Teodor Sigaev <teodor@sigaev.ru> wrote:
> YUriy Zhuravlev wrote:
>>
>> On Friday 06 November 2015 12:55:44 you wrote:
>>>
>>> Omitted bounds are common in other languages and would be handy. I
>>> don't think they'd cause any issues with multi-dimensional arrays or
>>> variable start-pos arrays.
>>
>>
>> And yet, what about my patch?
>
> My vote: let us do it, mean, omitting bounds. It simplifies syntax in rather
> popular queries.

+1  useful and intuitive

>> Discussions about ~ and{:} it seems optional.
>
> ~ is allowed as unary operator and therefore such syntax will introduce
> incompatibily/ambiguity.

+1  IMO this line of thinking is a dead end.  Better handled via
functions, not syntax

merlin

On Monday 30 November 2015 08:58:49 you wrote:
> +1  IMO this line of thinking is a dead end.  Better handled via
> functions, not syntax

Maybe then add array_pyslice(start, end) when start is 0 and with negative 
indexes? Only for 1D array.
What do you think?

-- 
YUriy Zhuravlev
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company

> On Friday 27 November 2015 17:23:35 Teodor Sigaev wrote:
>> 1
>> Documentation isn't very informative
> Added example with different results.
Perfect

>> 2
>> Seems, error messages are too inconsistent. If you forbid omitting bound in
>> assigment then if all cases error message should be the same or close.
> Done.  Skipping lower boundary is no longer an error.
>
> Thank you for your review.

Much better, but:

# create table xxx (a int[]);
# update xxx set a[2:] = '{1,2}';
UPDATE 0
# insert into xxx values ('{1,2,3,3,4,4,5}');
INSERT 0 1
# update xxx set a[2:] = '{1,2}';
ERROR:  cannot determine upper index for empty array

As I understand, update should fail with any array, so, first update should fail 
too. Am I right?


-- 
Teodor Sigaev                                   E-mail: teodor@sigaev.ru
  WWW: http://www.sigaev.ru/
 

On Tuesday 01 December 2015 15:30:47 Teodor Sigaev wrote:
> As I understand, update should fail with any array, so, first update should
> fail  too. Am I right?
You right. Done. New patch in attach.
--
YUriy Zhuravlev
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company

On Mon, Nov 30, 2015 at 3:05 PM, YUriy Zhuravlev
<u.zhuravlev@postgrespro.ru> wrote:
> On Monday 30 November 2015 08:58:49 you wrote:
>> +1  IMO this line of thinking is a dead end.  Better handled via
>> functions, not syntax
>
> Maybe then add array_pyslice(start, end) when start is 0 and with negative
> indexes? Only for 1D array.
> What do you think?

TBH, I'm not really thrilled about the concept in general; it (zero
based indexing support) doesn't meet the standard of necessity for
adding to the core API and as stated it's much to magical.  If it was
me, I'd be making a pgxn extension for zero based arrays that are zero
based;  it could be 100% SQL wrappers so I'd be pretty easy to install
for interested parties.

merlin

On Tuesday 01 December 2015 15:43:47 you wrote:
> On Tuesday 01 December 2015 15:30:47 Teodor Sigaev wrote:
> > As I understand, update should fail with any array, so, first update
> > should
> > fail  too. Am I right?
>
> You right. Done. New patch in attach.

Found error when omitted lower bound in INSERT like this:
INSERT INTO arrtest_s (a[:2], b[1:2]) VALUES ('{1,2,3,4,5}', '{7,8,9}');

I fix it in new patch.  Lower bound for new array is 1 by default.

Thanks.
--
YUriy Zhuravlev
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company

On Tuesday 01 December 2015 08:38:21 you wrote:
> it (zero
> based indexing support) doesn't meet the standard of necessity for
> adding to the core API and as stated it's much to magical. 

We do not touch the arrays, we simply create a function to access them with a 
comfortable behavior. Creating a separate array types in the form extension is 
very difficult IMHO.

-- 
YUriy Zhuravlev
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company

On Tue, Dec 1, 2015 at 8:46 AM, YUriy Zhuravlev
<u.zhuravlev@postgrespro.ru> wrote:
> On Tuesday 01 December 2015 08:38:21 you wrote:
>> it (zero
>> based indexing support) doesn't meet the standard of necessity for
>> adding to the core API and as stated it's much to magical.
>
> We do not touch the arrays, we simply create a function to access them with a
> comfortable behavior. Creating a separate array types in the form extension is
> very difficult IMHO.

Correct; what I'm saying is that we don't need core API support for
zero based array indexing.  A hypothetical extension could give 100%
function based support for that so that equivalents to all functions
are given: array_upper, array_lower, etc etc etc.  You are correct
that it could not implement alternative syntactical array features.

merlin

Some inconsistency (if we believe that omitted lower bound is equal to 1):
regression=# insert into arrtest_s values 
('[-1:9]={3,1,4,1,5,9,5,6,7,8,9}'::int[], null);
INSERT 0 1
regression=# UPDATE arrtest_s SET a[:2] = '{23, 24, 25}';
ERROR:  source array too small
regression=# UPDATE arrtest_s SET a[1:2] = '{23, 24, 25}';
UPDATE 1

Seems, omitting boundaries in insert/update isn't a good idea. I suggest to 
allow omitting only in select subscripting.

YUriy Zhuravlev wrote:
> On Tuesday 01 December 2015 15:43:47 you wrote:
>> On Tuesday 01 December 2015 15:30:47 Teodor Sigaev wrote:
>>> As I understand, update should fail with any array, so, first update
>>> should
>>> fail  too. Am I right?
>>
>> You right. Done. New patch in attach.
>
> Found error when omitted lower bound in INSERT like this:
> INSERT INTO arrtest_s (a[:2], b[1:2]) VALUES ('{1,2,3,4,5}', '{7,8,9}');
>
> I fix it in new patch.  Lower bound for new array is 1 by default.
>
> Thanks.
>
>
>
>

-- 
Teodor Sigaev                                   E-mail: teodor@sigaev.ru
  WWW: http://www.sigaev.ru/
 

On Friday 04 December 2015 16:52:48 Teodor Sigaev wrote:
> Seems, omitting boundaries in insert/update isn't a good idea. I suggest to
> allow omitting only in select subscripting.

It was my last attempt to do so. So now I agree, the most simple is now
disabled for insert and update. New patch in attach.
--
YUriy Zhuravlev
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company

On Wed, Dec 2, 2015 at 3:01 PM, Merlin Moncure <mmoncure@gmail.com> wrote:
> On Tue, Dec 1, 2015 at 8:46 AM, YUriy Zhuravlev
> <u.zhuravlev@postgrespro.ru> wrote:
>> On Tuesday 01 December 2015 08:38:21 you wrote:
>>> it (zero
>>> based indexing support) doesn't meet the standard of necessity for
>>> adding to the core API and as stated it's much to magical.
>>
>> We do not touch the arrays, we simply create a function to access them with a
>> comfortable behavior. Creating a separate array types in the form extension is
>> very difficult IMHO.
>
> Correct; what I'm saying is that we don't need core API support for
> zero based array indexing.

Yes.  I think adding new functions that use an indexing convention
inconsistent with the one we're using for everything else ought to be
completely out of the question.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

In the continuation of thread:
http://www.postgresql.org/message-id/19144.1450457693@sss.pgh.pa.us

>I'm dubious that the parsetree representation is well-chosen.
>Probably a single is_slice flag would have been better.

What do you mean? This flag is for what? You are about the A_Indices
node(lidx_default/uidx_default)?

All the other issues I fixed.

Thanks!

--
Uriy Zhuravlev
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company

Uriy Zhuravlev <u.zhuravlev@postgrespro.ru> writes:
>> I'm dubious that the parsetree representation is well-chosen.
>> Probably a single is_slice flag would have been better.

> What do you mean? This flag is for what? You are about the A_Indices 
> node(lidx_default/uidx_default)?

Yes.  Those flags are partially redundant with the subtree pointers being
NULL, and there are combinations that would be invalid (such as
lidx_default being set but lidx not being null), and it's pretty unobvious
what the difference in representation is between a non-slice case and a
slice case with only the upper index provided.  In fact, since you have
five syntaxes to represent, it's impossible for the two bools to
distinguish them all, which means that at least one case *must* be
identified by null-ness of a pointer contradicting what the corresponding
bool's setting would imply.  So this just seems like a mess to me.

I think it would come out cleaner if you had just one bool is_slice,
which corresponds directly to whether a colon was present.  The four
sub-possibilities of colon notation would be represented by combinations
of null and non-null lidx and uidx.  With is_slice false, the only valid
case is lidx==NULL, uidx!=NULL, as before for non-slice notation.
        regards, tom lane

On Tue, Dec 22, 2015 at 2:28 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Uriy Zhuravlev <u.zhuravlev@postgrespro.ru> writes:
>>> I'm dubious that the parsetree representation is well-chosen.
>>> Probably a single is_slice flag would have been better.
>
>> What do you mean? This flag is for what? You are about the A_Indices
>> node(lidx_default/uidx_default)?
>
> Yes.  Those flags are partially redundant with the subtree pointers being
> NULL, and there are combinations that would be invalid (such as
> lidx_default being set but lidx not being null), and it's pretty unobvious
> what the difference in representation is between a non-slice case and a
> slice case with only the upper index provided.  In fact, since you have
> five syntaxes to represent, it's impossible for the two bools to
> distinguish them all, which means that at least one case *must* be
> identified by null-ness of a pointer contradicting what the corresponding
> bool's setting would imply.  So this just seems like a mess to me.
>
> I think it would come out cleaner if you had just one bool is_slice,
> which corresponds directly to whether a colon was present.  The four
> sub-possibilities of colon notation would be represented by combinations
> of null and non-null lidx and uidx.  With is_slice false, the only valid
> case is lidx==NULL, uidx!=NULL, as before for non-slice notation.

Patch is still in the works and author is still active, so moved to next CF.
-- 
Michael

On понедельник, 21 декабря 2015 г. 20:28:43 MSK, Tom Lane wrote:
> With is_slice false, the only valid
> case is lidx==NULL, uidx!=NULL, as before for non-slice notation.
But now it becomes valid syntax:
select ('{1,2,3,4}'::int[])[NULL:NULL];
I do not think it's logical. Especially if in [:] function is used.
Unexpected behavior.

Thanks.
--
Uriy Zhuravlev
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company

Uriy Zhuravlev <u.zhuravlev@postgrespro.ru> writes:
> On понедельник, 21 декабря 2015 г. 20:28:43 MSK, Tom Lane wrote:
>> With is_slice false, the only valid
>> case is lidx==NULL, uidx!=NULL, as before for non-slice notation.

> But now it becomes valid syntax:
> select ('{1,2,3,4}'::int[])[NULL:NULL];
> I do not think it's logical. Especially if in [:] function is used.
> Unexpected behavior. 

I think you are confused about the difference between a NULL constant
(which would give rise to an A_Const syntax tree node) and a NULL
syntax tree pointer (which cannot arise from any actual syntactical
construct, and would only be present if the grammar put it there due
to lack of any corresponding item in the input).
        regards, tom lane

> I think you are confused about the difference between a NULL constant
> (which would give rise to an A_Const syntax tree node) and a NULL
> syntax tree pointer (which cannot arise from any actual syntactical
> construct, and would only be present if the grammar put it there due
> to lack of any corresponding item in the input).
>
>             regards, tom lane

You're right. I will try to provide a patch as soon as possible.
Thanks.

--
Yury Zhuravlev
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company

New patch version in attachment.
Thanks.

--
Yury Zhuravlev
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company

Yury Zhuravlev <u.zhuravlev@postgrespro.ru> writes:
> New patch version in attachment.  

It's still awfully short on comments, but I'll see what I can do with it.
        regards, tom lane

Yury Zhuravlev <u.zhuravlev@postgrespro.ru> writes:
> New patch version in attachment.  

I've committed this with a number of revisions, mostly but not entirely
cosmetic.  Worthy of note:

* I did not like the way you were inserting the replacement subscript
values:

+            arrays = (AnyArrayType *)DatumGetArrayTypeP(array_source);
+            indexexpr = AARR_LBOUND(arrays)[i] + AARR_DIMS(arrays)[i] - 1;

If the source array is toasted, this causes an extra detoast operation
for *each* omitted subscript.  That could be pretty high overhead for
a large array.  The best way to avoid that is to postpone the actual
substitution of the replacement subscript values into array_get_slice
and array_set_slice; which complicates their APIs a bit more, but those
were pretty long argument lists already.

* Having done that, there was no very good reason for the blanket
prohibition on using omitted subscripts in the slice-set case.  We only
really need to fail if we're constructing the array from scratch, when
we don't have any existing subscript limits to substitute.
        regards, tom lane

> I've committed this with a number of revisions, mostly but not entirely
> cosmetic.

Thanks Tom!
I feel I still have a lot to learn Postgres to choose the right solution.
Your comments are very valuable.

--
Yury Zhuravlev
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company