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
On Thu, Oct 12, 2006 at 06:58:52PM -0400, Tom Lane wrote:
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
Martijn van Oosterhout kleptog@svana.org writes:
What this really calls for is a type that users are forbidden to
interact with directly. Basically, the type may only be used by C
functions and such C functions may not appear in an SQL query.
That's not really the flavor of solution I'd like
* Tom Lane ([EMAIL PROTECTED]) wrote:
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))
and get the same result as aggregating over the values 1 and 2. The
trick is to make sure that my_sfunc
Stephen Frost [EMAIL PROTECTED] 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
* Tom Lane ([EMAIL PROTECTED]) wrote:
Stephen Frost [EMAIL PROTECTED] writes:
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
Stephen Frost [EMAIL PROTECTED] writes:
Additionally, we'd have to be
able to mark the types as being polymorhpic along the same lines as
anyelement/anyarray.
What for?
So that the finalfunc can be polymorphic along the lines of my suggested
aaccum_sfunc(anyarray,anyelement) returns
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
* 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 much
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 change
* 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 this
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 the
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 what
Greetings,
Please find below a patch to add the array_accum aggregate as a
built-in using two new C functions defined in array_userfuncs.c.
These functions simply expose the pre-existing efficient array
building routines used elsewhere in the backend (accumArrayResult
and
14 matches
Mail list logo
