Skip site navigation (1) Skip section navigation (2)

Re: [GENERAL] Array assignment behavior (was Re: Stored procedure array limits)

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: "John D(dot) Burger" <john(at)mitre(dot)org>
Cc: Postgres General <pgsql-general(at)postgresql(dot)org>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>, pgsql-admin(at)postgresql(dot)org
Subject: Re: [GENERAL] Array assignment behavior (was Re: Stored procedure array limits)
Date: 2006-09-29 17:59:27
Message-ID: 18110.1159552767@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-adminpgsql-generalpgsql-hackers
"John D. Burger" <john(at)mitre(dot)org> writes:
>>> As of 8.2 we could allow assignment to
>>> arbitrary positions by filling the intermediate positions with nulls.
>>> The code hasn't actually been changed to allow that, but it's  
>>> something we could consider doing now.
>> 
>> At first blush, this strikes me as a bit too magical/implicit. Are  
>> there other languages where sequences behave similarly?

>>> perl -e '@A = (1, 2, 3); print "@A\n"; $A[10] = 10; print "@A\n";'
> 1 2 3
> 1 2 3        10

Actually, now that I look closely, I think the SQL spec demands exactly
this.  Recall that SQL99 only allows one-dimensional, lower-bound-one
arrays.  The specification for UPDATE ... SET C[I] = SV ... reads

              Case:

              i) If the value of C is null, then an exception condition is
                 raised: data exception - null value in array target.

             ii) Otherwise:

                 1) Let N be the maximum cardinality of C.

                 2) Let M be the cardinality of the value of C.

                 3) Let I be the value of the <simple value specification>
                   immediately contained in <update target>.

                 4) Let EDT be the element type of C.

                 5) Case:

                   A) If I is greater than zero and less than or equal to
                      M, then the value of C is replaced by an array A
                      with element type EDT and cardinality M derived as
                      follows:

                      I) For j varying from 1 (one) to I-1 and from I+1 to
                        M, the j-th element in A is the value of the j-th
                        element in C.

                     II) The I-th element of A is set to the specified
                        update value, denoted by SV, by applying the
                        General Rules of Subclause 9.2, "Store assignment",
                        to the I-th element of A and SV as TARGET and
                        VALUE, respectively.

                   B) If I is greater than M and less than or equal to
                      N, then the value of C is replaced by an array A
                      with element type EDT and cardinality I derived as
                      follows:

                      I) For j varying from 1 (one) to M, the j-th element
                        in A is the value of the j-th element in C.

                     II) For j varying from M+1 to I-1, the j-th element in
                        A is the null value.

                    III) The I-th element of A is set to the specified
                        update value, denoted by SV, by applying the
                        General Rules of Subclause 9.2, "Store assignment",
                        to the I-th element of A and SV as TARGET and
                        VALUE, respectively.

                   C) Otherwise, an exception condition is raised: data
                      exception - array element error.

We currently violate case i by allowing the null array value to be
replaced by a single-element array.  I'm disinclined to change that,
as I think our behavior is more useful than the spec's.  But case ii.5.B
pretty clearly describes null-fill, so I think we'd better do that, now
that we can.

			regards, tom lane

In response to

Responses

pgsql-hackers by date

Next:From: Erik JonesDate: 2006-09-29 18:51:59
Subject: Re: [GENERAL] Array assignment behavior (was Re: Stored procedure
Previous:From: Erik JonesDate: 2006-09-29 17:37:30
Subject: Re: [GENERAL] Array assignment behavior (was Re: Stored procedure

pgsql-admin by date

Next:From: Sriram DandapaniDate: 2006-09-29 17:59:54
Subject: Re: autovacuum ignore tables
Previous:From: Erik JonesDate: 2006-09-29 17:37:30
Subject: Re: [GENERAL] Array assignment behavior (was Re: Stored procedure

pgsql-general by date

Next:From: snacktimeDate: 2006-09-29 18:27:14
Subject: Re: using schema's for data separation
Previous:From: Rick SchumeyerDate: 2006-09-29 17:45:34
Subject: pg web hosting with tsearch2?

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group