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 Com
Yury Zhuravlev 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
*)DatumGet
Yury Zhuravlev 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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://ww
New patch version in attachment.
Thanks.
--
Yury Zhuravlev
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Companydiff --git a/doc/src/sgml/array.sgml b/doc/src/sgml/array.sgml
index 4385a09..305cabb 100644
--- a/doc/src/sgml/array.sgml
+++ b/doc/src/sgml/array.sgml
@@ -
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 correspo
Uriy Zhuravlev 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];
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 [:] functi
On Tue, Dec 22, 2015 at 2:28 AM, Tom Lane wrote:
> Uriy Zhuravlev 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/ui
Uriy Zhuravlev 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
In the continuation of thread:
http://www.postgresql.org/message-id/19144.1450457...@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(li
On Wed, Dec 2, 2015 at 3:01 PM, Merlin Moncure wrote:
> On Tue, Dec 1, 2015 at 8:46 AM, YUriy Zhuravlev
> 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 muc
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 i
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
On Tue, Dec 1, 2015 at 8:46 AM, YUriy Zhuravlev
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
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. Creatin
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
On Mon, Nov 30, 2015 at 3:05 PM, YUriy Zhuravlev
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 1
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 Companyd
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.
D
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 Profess
On Thu, Nov 26, 2015 at 6:08 AM, Teodor Sigaev 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
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 sh
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 se
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
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 Pr
2015-11-11 12:25 GMT+01:00 YUriy Zhuravlev :
> 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 pa
On Mon, Nov 9, 2015 at 8:23 PM, Pavel Stehule
wrote:
> 2015-11-09 17:55 GMT+01:00 Alexander Korotkov :
>
>> On Mon, Nov 9, 2015 at 4:53 PM, Pavel Stehule
>> wrote:
>>
>>> 2015-11-09 14:44 GMT+01:00 YUriy Zhuravlev :
>>>
On Monday 09 November 2015 13:50:20 Pavel Stehule wrote:
> New sym
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.
Thank
2015-11-09 17:55 GMT+01:00 Alexander Korotkov :
> On Mon, Nov 9, 2015 at 4:53 PM, Pavel Stehule
> wrote:
>
>> 2015-11-09 14:44 GMT+01:00 YUriy Zhuravlev :
>>
>>> On Monday 09 November 2015 13:50:20 Pavel Stehule wrote:
>>> > New symbols increase a complexity of our code and our documentation.
>>>
On Mon, Nov 9, 2015 at 4:53 PM, Pavel Stehule
wrote:
> 2015-11-09 14:44 GMT+01:00 YUriy Zhuravlev :
>
>> 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 functi
2015-11-09 14:44 GMT+01:00 YUriy Zhuravlev :
> 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
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.
2015-11-09 13:50 GMT+01:00 Pavel Stehule :
>
>
> 2015-11-09 13:32 GMT+01:00 YUriy Zhuravlev :
>
>> 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 querie
2015-11-09 13:38 GMT+01:00 YUriy Zhuravlev :
> 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?
>
The own implementation
2015-11-09 13:32 GMT+01:00 YUriy Zhuravlev :
> 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
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
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 po
On 11/9/15, YUriy Zhuravlev 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 name
2015-11-09 13:07 GMT+01:00 YUriy Zhuravlev :
> 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 whe
>From: pgsql-hackers-ow...@postgresql.org
>[mailto:pgsql-hackers-ow...@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.
>
>
>
>20
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.
--
2015-11-09 12:36 GMT+01:00 YUriy Zhuravlev :
> 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
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
sta
On Fri, Nov 6, 2015 at 9:44 PM, Jim Nasby 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
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 ha
On Thursday 05 November 2015 23:45:53 you wrote:
> On Thu, Nov 5, 2015 at 9:57 AM, YUriy Zhuravlev
>
> 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 we
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
Th
On Thursday, November 5, 2015, Craig Ringer wrote:
> On 6 November 2015 at 12:45, Robert Haas > wrote:
> > On Thu, Nov 5, 2015 at 9:57 AM, YUriy Zhuravlev
> > > wrote:
> >> Hello hackers.
> >> There are comments to my patch? Maybe I should create a separate thread?
> >> Thanks.
> >
> > You shoul
On 6 November 2015 at 12:45, Robert Haas wrote:
> On Thu, Nov 5, 2015 at 9:57 AM, YUriy Zhuravlev
> 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
On Thu, Nov 5, 2015 at 9:57 AM, YUriy Zhuravlev
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 k
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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscri
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 Profess
On Fri, Oct 9, 2015 at 8: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
On Fri, Oct 9, 2015 at 6:27 PM, Andrew Dunstan wrote:
> 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: -
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 probabl
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 a
56 matches
Mail list logo
