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 |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-admin pgsql-general pgsql-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
From | Date | Subject | |
---|---|---|---|
Next Message | Sriram Dandapani | 2006-09-29 17:59:54 | Re: autovacuum ignore tables |
Previous Message | Erik Jones | 2006-09-29 17:37:30 | Re: [GENERAL] Array assignment behavior (was Re: Stored procedure |
From | Date | Subject | |
---|---|---|---|
Next Message | snacktime | 2006-09-29 18:27:14 | Re: using schema's for data separation |
Previous Message | Rick Schumeyer | 2006-09-29 17:45:34 | pg web hosting with tsearch2? |
From | Date | Subject | |
---|---|---|---|
Next Message | Erik Jones | 2006-09-29 18:51:59 | Re: [GENERAL] Array assignment behavior (was Re: Stored procedure |
Previous Message | Erik Jones | 2006-09-29 17:37:30 | Re: [GENERAL] Array assignment behavior (was Re: Stored procedure |