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
