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

2006-09-29 Thread Casey Duncan

On Sep 29, 2006, at 9:14 AM, Tom Lane wrote:


[ expanding this thread, as it now needs wider discussion ]

Paul B. Anderson [EMAIL PROTECTED] writes:

Actually, I was not filling all of the arrays in sequential order.  I
added code to initialize them in order and the function seems to be
working now.  Is that a known problem?


Well, it's a documented behavior: section 8.10.4 saith

A stored array value can be enlarged by assigning to an element
adjacent to those already present, or by assigning to a slice
that is adjacent to or overlaps the data already present.

Up to 8.2 we didn't have a lot of choice about this, because  
without any
ability to have nulls embedded in arrays, there wasn't any sane  
thing to

do with the intermediate positions if you assigned to an element not
adjacent to the existing range.  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.

Comments?


At first blush, this strikes me as a bit too magical/implicit. Are  
there other languages where sequences behave similarly? The best  
analogy that comes to mind is sparse files, but in that case there is  
an implicit contract that the intervening empty regions do not  
actually occupy physical space, doesn't sound like that's true here.


I think the result of this change would be more difficult debugging  
of off-by-one errors and their ilk, rather than actually being a real  
benefit.


OTOH, perhaps there is a real use-case I am missing here. I don't see  
the rest of this thread on GENERAL and I couldn't find it searching  
the archives, where did it come from?


-Casey


---(end of broadcast)---
TIP 6: explain analyze is your friend


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

2006-09-29 Thread John D. Burger

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 310

- John D. Burger
  MITRE


---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster


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

2006-09-29 Thread Tom Lane
John D. Burger [EMAIL PROTECTED] 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 310

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

---(end of broadcast)---
TIP 5: don't forget to increase your free space map settings