Martijn van Oosterhout writes:
> --f2QGlHpHGjS2mn6Y
> On Tue, Apr 11, 2006 at 11:22:53PM +0200, Andreas Tille wrote:
>> I'm lacking experience here so I perfectly trust you that keeping
>> the default case as it is. The question is, whether adding an
>> option to change the default might make sen
Andreas Tille <[EMAIL PROTECTED]> writes:
> I'm lacking experience here so I perfectly trust you that keeping
> the default case as it is. The question is, whether adding an
> option to change the default might make sense.
I don't think so. The current API contract for aggregate functions is
tha
On Tue, Apr 11, 2006 at 11:22:53PM +0200, Andreas Tille wrote:
> On Tue, 11 Apr 2006, Tom Lane wrote:
>
> >We could maybe change things so that the finalfunc isn't run unless the
> >result value is actually demanded in the SELECT list or HAVING clause,
> >but for 99.99% of applications checking th
On Tue, 11 Apr 2006, Tom Lane wrote:
We could maybe change things so that the finalfunc isn't run unless the
result value is actually demanded in the SELECT list or HAVING clause,
but for 99.99% of applications checking that would be a waste of cycles,
so I'm disinclined to do it.
I'm lacking
On Tue, 11 Apr 2006, Martijn van Oosterhout wrote:
Because there were no non-null rows, the system passed a NULL to the
final func. Seems you have two ways of dealing with this. Mark the
finalfunc as STRICT so the system won't call it with NULL. Or give the
agrregate an INITCOND which is an empt
Martijn van Oosterhout writes:
> The problem in your example is that you're using aggrgates in the case
> statement.
Yeah. The aggregate results are all computed before we start to evaluate
the SELECT output list --- the fact that the aggregate is referenced
within a CASE doesn't save you if the
On Tue, Apr 11, 2006 at 04:43:33PM +0200, Andreas Tille wrote:
> Hi,
>
> when dealing with a bug in the postgresql-plr interface I think
> I found a suboptimal method to process CASE statements. First
> to the problem:
> SELECT median(nonnull), median(mightbenull) from plrtest where flag = 0;
>
Hi,
when dealing with a bug in the postgresql-plr interface I think
I found a suboptimal method to process CASE statements. First
to the problem:
I'm using the Debian packaged version of PLR version 0.6.2-2 (Debian
testing) and found a problem calculating median from a set of
values that contai
