I wrote:
> Attached is a draft patch against HEAD for this.
I've finished back-porting this. I'm not going to commit it until 9.2.0
is definitely gold, but attached is the 9.1 version of the patch, if
you'd like to try it and verify that it fixes your original problem.
r
BTW, after considerable fooling around with Vik's example, I've been
able to produce a regression test case that fails in all PG versions
with WITH:
with
A as ( select q2 as id, (select q1) as x from int8_tbl ),
B as ( select id, row_number() over (partition by id) as r from A ),
C as ( select A.i
Thom Brown writes:
> On 5 September 2012 05:09, Tom Lane wrote:
>> Attached is a draft patch against HEAD for this. I think it makes the
>> planner's handling of outer-level Params far less squishy than it's ever
>> been, but it is rather a large change. Not sure whether to risk pushing
>> it i
On 5 September 2012 05:09, Tom Lane wrote:
> I wrote:
>> I think probably the best fix is to rejigger things so that Params
>> assigned by different executions of SS_replace_correlation_vars and
>> createplan.c can't share PARAM_EXEC numbers. This will result in
>> rather larger ecxt_param_exec_v
On Wed, Sep 5, 2012 at 6:09 AM, Tom Lane wrote:
> I wrote:
> > I think probably the best fix is to rejigger things so that Params
> > assigned by different executions of SS_replace_correlation_vars and
> > createplan.c can't share PARAM_EXEC numbers. This will result in
> > rather larger ecxt_pa
I wrote:
> I think probably the best fix is to rejigger things so that Params
> assigned by different executions of SS_replace_correlation_vars and
> createplan.c can't share PARAM_EXEC numbers. This will result in
> rather larger ecxt_param_exec_vals arrays at runtime, but the array
> entries are
I wrote:
> Vik Reykja writes:
>> Hello. It took me a while to get a version of this that was independent of
>> my data, but here it is. I don't understand what's going wrong but if you
>> change any part of this query (or at least any part I tried), the correct
>> result is returned.
> Huh. 9.
Vik Reykja writes:
> Hello. It took me a while to get a version of this that was independent of
> my data, but here it is. I don't understand what's going wrong but if you
> change any part of this query (or at least any part I tried), the correct
> result is returned.
Huh. 9.1 gets the wrong
Hello. It took me a while to get a version of this that was independent of
my data, but here it is. I don't understand what's going wrong but if you
change any part of this query (or at least any part I tried), the correct
result is returned.
This script will reproduce it:
=
create table t
