Yup, I tried the same exact thing :) I wouldn't mind seeing some better
support in plpgsql either. However, anyone can create their own type so I
guess it isn't much of a problem.
I updated my code to use points instead, and more meaningful identifiers.
-----------------------------------------------------------
create function float_gmean(point) returns float as '
BEGIN
return ($1[0]^(1/($1[1])));
END;
' language 'plpgsql';
create function float_gmean_accum(point,float) returns point as '
BEGIN
RETURN point(($1[0]*$2),($1[1]+1));
END;
' language 'plpgsql';
create aggregate gmean
(basetype=float,sfunc=float_gmean_accum,stype=point,finalfunc=float_gmean,initcond='(1.0,0.0)');
-----------------------------------------------------------
> I tried to do this:
>
> create function a1(float[2],float) returns float[2] as '
> declare
> ret float[2];
> begin
> ret := $1;
> ret[1] := ret[1] * $2;
> ret[2] := ret[2] + 1;
> return ret;
> end' language plpgsql;
>
> but it failed with syntax errors --- plpgsql doesn't understand the
> notation "var[subscript] := something". Someone oughta dig into it
> and fix that.
>
> In the meantime I think the most practical way to do this task in
> plpgsql is to abuse the built-in "point" type, which can be treated
> as an array of 2 floats:
>
> regression=# create function a1(point,float) returns point as '
> regression'# begin
> regression'# return point($1[0] * $2, $1[1] + 1);
> regression'# end' language plpgsql;
> CREATE
> regression=# select a1('(2,3)'::point, 44);
> a1
> --------
> (88,4)
> (1 row)
>
> Note that the subscripts are [0],[1] not [1],[2] ... a bit of legacy
> incompatibility ...
>
> regards, tom lane
>
> ---------------------------(end of broadcast)---------------------------
> TIP 4: Don't 'kill -9' the postmaster