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
* 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
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
* 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_
Martijn van Oosterhout 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 to have. Ideall
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",
> > exc
