Re: [HACKERS] array_accum aggregate - Mailing list pgsql-patches

From Tom Lane
Subject Re: [HACKERS] array_accum aggregate
Date
Msg-id 16466.1160755322@sss.pgh.pa.us
Whole thread Raw
In response to Re: [HACKERS] array_accum aggregate  (Stephen Frost <sfrost@snowman.net>)
Responses Re: [HACKERS] array_accum aggregate  (Stephen Frost <sfrost@snowman.net>)
List pgsql-patches
Stephen Frost <sfrost@snowman.net> writes:
>> That's not really the flavor of solution I'd like to have.  Ideally,
>> it'd actually *work* to write
>> my_ffunc(my_sfunc(my_sfunc(null, 1), 2))

> In general I like this idea but there are some complications, the main
> one being where would the memory be allocated?

In the agg context if called with that context, else
CurrentMemoryContext will do fine.

> The other issue is, in the above scenario
> is it acceptable to modify the result of my_sfunc(null, 1) in the ,2
> call?

Yes, because the only place a nonnull value of the type could have come
from is a my_sfunc call; since it's a pseudotype, we don't allow it on
disk.  (We might also need a hack to prevent the type from being used as
a record-type component ... not sure if that comes for free with being a
pseudotype currently.)

> As for a type for each such aggregate, that seems reasonable to me,
> honestly.

The ugly part is that we'd still need a way for the planner to recognize
this class of types.

> Additionally, we'd have to be
> able to mark the types as being polymorhpic along the same lines as
> anyelement/anyarray.

What for?

            regards, tom lane

pgsql-patches by date:

Previous
From: Stephen Frost
Date:
Subject: Re: [HACKERS] array_accum aggregate
Next
From: Stephen Frost
Date:
Subject: Re: [HACKERS] array_accum aggregate