What is the status of this feature addition?
---
Stephen Frost wrote:
-- Start of PGP signed section.
> * Tom Lane ([EMAIL PROTECTED]) wrote:
> > (However, now that we support nulls in arrays, meseems a more consistent
> > d
I wrote:
> aggregate_state would have no other uses in the system, and its input
> and output functions would raise an error, so type safety is assured
> --- there would be no way to call either the sfunc or ffunc "manually",
> except by passing a NULL value, which should be safe because that's wha
Stephen Frost <[EMAIL PROTECTED]> writes:
> Another alternative would be to provide a seperate area for each
> aggregate to put any other information it needs.
I'm not convinced that that's necessary --- the cases we have at hand
suggest that the transition function is perfectly capable of doing t
* Tom Lane ([EMAIL PROTECTED]) wrote:
> (However, now that we support nulls in arrays, meseems a more consistent
> definition would be that it allows null inputs and just includes them in
> the output. So probably you do need it non-strict.)
This was my intention.
> I'm inclined to think that th
Stephen Frost <[EMAIL PROTECTED]> writes:
> * Neil Conway ([EMAIL PROTECTED]) wrote:
>> There is no guarantee why SQL NULL and PG_RETURN_XYZ(NULL) refer to the
>> same thing -- use PG_RETURN_NULL() to return a SQL NULL value, or just
>> make the function strict.
> Huh, alright. I'll probably just
* Neil Conway ([EMAIL PROTECTED]) wrote:
> On Wed, 2006-10-11 at 00:51 -0400, Stephen Frost wrote:
> > Here, the actual state type for any aggregate call is the array type
> > !having the actual input type as elements. Note: array_accum() is now
> > !a built-in aggregate which uses a
On Wed, 2006-10-11 at 00:51 -0400, Stephen Frost wrote:
> An array_accum aggregate has existed in the documentation for quite
> some time using the inefficient (for larger arrays) array_append
> routine.
My vague recollection is that array_accum() is only defined in the
documentation because there
