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

2006-09-29 Thread Tom Lane
[ 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?

regards, tom lane

---(end of broadcast)---
TIP 3: Have you checked our extensive FAQ?

   http://www.postgresql.org/docs/faq


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

2006-09-29 Thread Paul B. Anderson




It seems that the suggestion to fill intermediate positions with
NULLs would be preferable to the current behavior. 

I know of no requirement to populate arrays in sequence in any other
language so I think other programmers would be surprised too by the
current behavior.

Paul


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?

			regards, tom lane

---(end of broadcast)---
TIP 9: In versions below 8.0, the planner will ignore your desire to
   choose an index scan if your joining column's datatypes do not
   match

.