Jeff Davis writes:
> On Tue, 2011-07-12 at 11:20 -0400, Tom Lane wrote:
>> So far as I can see, the failure only
>> occurs if we have a plain (non-grouping) Agg node, which implies that
>> the user is trying to use windowing functions on a result set that's
>> guaranteed to contain exactly one agg
On Tue, 2011-07-12 at 11:20 -0400, Tom Lane wrote:
> So far as I can see, the failure only
> occurs if we have a plain (non-grouping) Agg node, which implies that
> the user is trying to use windowing functions on a result set that's
> guaranteed to contain exactly one aggregated row. That seems p
Excerpts from Tom Lane's message of mar jul 12 11:20:39 -0400 2011:
> I wrote:
> > ... so I guess the answer is that this code ought to avoid adding Vars that
> > are only mentioned within aggregates.
>
> The cleanest way to fix this would involve adding another flag parameter
> to flatten_tlist a
I wrote:
> ... so I guess the answer is that this code ought to avoid adding Vars that
> are only mentioned within aggregates.
The cleanest way to fix this would involve adding another flag parameter
to flatten_tlist and pull_var_clause. This is no problem to do in HEAD
or even 9.1, but I'm a bit
Jeff Davis writes:
> In branch postgresql/master:
> SELECT SUM(SUM(a)) OVER ()
> FROM (SELECT NULL::int4 AS a WHERE FALSE) R;
> ERROR: XX000: cannot extract attribute from empty tuple slot
Huh, interesting.
> Honestly, I'm not sure what the semantics of that are supposed to be. Is
> it even al
In branch postgresql/master:
SELECT SUM(SUM(a)) OVER ()
FROM (SELECT NULL::int4 AS a WHERE FALSE) R;
ERROR: XX000: cannot extract attribute from empty tuple slot
Honestly, I'm not sure what the semantics of that are supposed to be. Is
it even allowed by the standard?
Regards,
Jeff Dav
