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
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
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
11 matches
Mail list logo
