Re: Manipulating complex types as non-contiguous structures in-memory

I wrote:
> Here's an 0.4 version, in which I've written some user docs, refactored
> the array-specific code into a more reasonable arrangement, and adjusted
> a lot of the built-in array functions to support expanded arrays directly.
> This is about as far as I feel a need to take the latter activity, at
> least for now; there are a few remaining operations that might be worth
> converting but it's not clear they'd really offer much benefit.

Attached is an updated version. Aside from rebasing over some recent
commits that touched the same areas, this improves one more case, which
is plpgsql arrays with typmods. I noticed that while

create or replace function arraysetnum(n int) returns numeric[] as $$
declare res numeric[] := '{}';
begin
for i in 1 .. n loop
res[i] := i;
end loop;
return res;
end
$$ language plpgsql strict;

was nicely speedy, performance went back in the toilet again as soon as
you stuck a typmod onto the array, for example

declare res numeric(20,0)[] := '{}';

The reason is that exec_cast_value would then insist on feeding the whole
array through I/O conversion to apply the typmod :-(. This was in fact
completely useless activity because we had already carefully applied the
typmod to the new array element; but exec_cast_value didn't know that.
In the attached patch, I've dealt with this by teaching exec_eval_expr,
exec_assign_value, exec_cast_value, etc to track typmods not just type
OIDs. In this way we avoid a useless conversion whenever a value is known
to match the desired typmod already. This is probably something that
should've been done to plpgsql a very long time ago; the overhead is
really minimal and the potential savings when dealing with
length-constrained variables is significant.

regards, tom lane