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

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

From: Casey Duncan <casey(at)pandora(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: "Paul B(dot) Anderson" <paul(dot)a(at)pnlassociates(dot)com>,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 array limits)
Date: 2006-09-29 16:35:25
Message-ID: 595CA7DC-7EC2-47B6-A894-DCD0ED3825F3@pandora.com (view raw or flat)
Thread:
Lists: pgsql-adminpgsql-generalpgsql-hackers
On Sep 29, 2006, at 9:14 AM, 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?

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


In response to

Responses

pgsql-hackers by date

Next:From: John D. BurgerDate: 2006-09-29 16:40:48
Subject: Re: [GENERAL] Array assignment behavior (was Re: Stored procedure array limits)
Previous:From: Walter CruzDate: 2006-09-29 16:25:40
Subject: a little doubr about domains and pl/python

pgsql-admin by date

Next:From: John D. BurgerDate: 2006-09-29 16:40:48
Subject: Re: [GENERAL] Array assignment behavior (was Re: Stored procedure array limits)
Previous:From: Tom LaneDate: 2006-09-29 16:14:11
Subject: Array assignment behavior (was Re: Stored procedure array limits)

pgsql-general by date

Next:From: John D. BurgerDate: 2006-09-29 16:37:58
Subject: Re: Expected accuracy of planner statistics
Previous:From: Tom LaneDate: 2006-09-29 16:14:11
Subject: Array assignment behavior (was Re: Stored procedure array limits)

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