Re: Some questions about the array. - Mailing list pgsql-hackers

From Alexander Korotkov
Subject Re: Some questions about the array.
Date
Msg-id CAPpHfdtiJkS11pz3yVnxsBU57qJ_8Q7G6gO5LmjrHvo_1S_oPw@mail.gmail.com
Whole thread Raw
In response to Re: Some questions about the array.  (Pavel Stehule <pavel.stehule@gmail.com>)
List pgsql-hackers
On Mon, Nov 9, 2015 at 8:23 PM, Pavel Stehule <pavel.stehule@gmail.com> wrote:
2015-11-09 17:55 GMT+01:00 Alexander Korotkov <a.korotkov@postgrespro.ru>:
On Mon, Nov 9, 2015 at 4:53 PM, Pavel Stehule <pavel.stehule@gmail.com> wrote:
2015-11-09 14:44 GMT+01:00 YUriy Zhuravlev <u.zhuravlev@postgrespro.ru>:
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.

It isn't solution. The any syntax/behave change have to have stronger motivation. We had so talk about it 20 years ago :(

Assuming array[~n] has a current meaning, could we give a try to new syntax which doesn't have current meaning? Not yet sure what exactly it could be...

Using this syntax can introduce compatibility issues - http://www.postgresql.org/docs/9.1/static/sql-createoperator.html

I actually meant some other syntax which doesn't introduce compatibility issues. For instance, array{n} doesn't have meaning in current syntax AFAICS.

------

Alexander Korotkov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company 

pgsql-hackers by date:

Previous
From: Michael Paquier
Date:
Subject: Re: proposal: multiple psql option -c
Next
From: Robert Haas
Date:
Subject: Re: Parallel Seq Scan