"some Salesforce folks" that would be me! It looks like I didn't quite
communicate to Tom just what I was looking for as I do indeed want to have
a variable number of "any" types, as:
CREATE AGGREGATE FOO ( ANYELEMENT, <more types>, VARIADIC "any") (
...
STYPE = ANYARRAY
...)
so the corresponding transition function would be
CREATE FUNCTION FOO_sfunc( ANYARRAY, ANYELEMENT, <more types>, VARIADIC
"any") RETURNS ANYARRAY
and the final func is
CREATE FUNCTION FOO_ffunc( ANYARRAY ) RETURNS ANYELEMENT
The functions are in C, and I cheat and actually use the ANYARRAY
transition variable as a struct just keeping the varlena length correct
(thanks to Tom for that idea). Currently I just support a fixed number of
"any" args but really need to have that be variable.
So supporting VARIADIC "any" for user defined aggregates would be most
useful.
On Thu, Jul 18, 2013 at 7:09 PM, Tom Lane <t...@sss.pgh.pa.us> wrote:
> Noah Misch <n...@leadboat.com> writes:
> > (I don't know whether VARIADIC transition functions work today, but that
> would
> > become an orthogonal project.)
>
> Coincidentally enough, some Salesforce folk were asking me about allowing
> VARIADIC aggregates just a few days ago. I experimented enough to find
> out that if you make an array-accepting transition function, and then
> force the aggregate's pg_proc entry to look like it's variadic (by
> manually setting provariadic and some other fields), then everything
> seems to Just Work: the parser and executor are both fine with it.
> So I think all that's needed here is to add some syntax support to
> CREATE AGGREGATE, and probably make some tweaks in pg_dump. I was
> planning to go work on that sometime soon.
>
> Having said that, though, what Andrew seemed to want was VARIADIC ANY,
> which is a *completely* different kettle of fish, since the actual
> parameters can't be converted to an array. I'm not sure if that's
> as easy to support.
>
> regards, tom lane
>
>
