Re: Array assignment behavior (was Re: Stored procedure array

From: "Paul B(dot) Anderson" <paul(dot)a(at)pnlassociates(dot)com>
To: pgsql-admin(at)postgresql(dot)org, pgsql-general(at)postgresql(dot)org, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Array assignment behavior (was Re: Stored procedure array
Date: 2006-09-29 17:08:15
Message-ID: 451D52FF.5000602@pnlassociates.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-admin pgsql-general pgsql-hackers

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
>
> .
>
>

In response to

Responses

Browse pgsql-admin by date

  From Date Subject
Next Message Jim Nasby 2006-09-29 17:21:52 Re: [JDBC] number of transactions doubling
Previous Message John D. Burger 2006-09-29 16:40:48 Re: [GENERAL] Array assignment behavior (was Re: Stored procedure array limits)

Browse pgsql-general by date

  From Date Subject
Next Message Erik Jones 2006-09-29 17:37:30 Re: [GENERAL] Array assignment behavior (was Re: Stored procedure
Previous Message Dimitri Fontaine 2006-09-29 16:58:06 Re: benchmark suite

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2006-09-29 17:24:15 Re: Nulls, arrays, records, IS NULL, IS DISTINCT FROM
Previous Message David Fetter 2006-09-29 17:06:31 Re: Nulls, arrays, records, IS NULL, IS DISTINCT FROM