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

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

From: Erik Jones <erik(at)myemma(dot)com>
To: "Paul B(dot) Anderson" <paul(dot)a(at)pnlassociates(dot)com>
Cc: pgsql-admin(at)postgresql(dot)org, pgsql-general(at)postgresql(dot)org,pgsql-hackers(at)postgresql(dot)org
Subject: Re: [GENERAL] Array assignment behavior (was Re: Stored procedure
Date: 2006-09-29 17:37:30
Message-ID: 451D59DA.7090203@myemma.com (view raw or flat)
Thread:
Lists: pgsql-adminpgsql-generalpgsql-hackers
Yep, that definitely threw me the first time I encountered it.

Paul B. Anderson wrote:
> 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" <paul(dot)a(at)pnlassociates(dot)com> 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
>>
>> .
>>
>>   


-- 
erik jones <erik(at)myemma(dot)com>
software development
emma(r)


In response to

pgsql-hackers by date

Next:From: Tom LaneDate: 2006-09-29 17:59:27
Subject: Re: [GENERAL] Array assignment behavior (was Re: Stored procedure array limits)
Previous:From: Tom LaneDate: 2006-09-29 17:32:44
Subject: Re: a little doubr about domains and pl/python

pgsql-admin by date

Next:From: Tom LaneDate: 2006-09-29 17:59:27
Subject: Re: [GENERAL] Array assignment behavior (was Re: Stored procedure array limits)
Previous:From: Jim NasbyDate: 2006-09-29 17:21:52
Subject: Re: [JDBC] number of transactions doubling

pgsql-general by date

Next:From: Rick SchumeyerDate: 2006-09-29 17:45:34
Subject: pg web hosting with tsearch2?
Previous:From: Paul B. AndersonDate: 2006-09-29 17:08:15
Subject: Re: Array assignment behavior (was Re: Stored procedure array

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