Re: BUG #17495: Regression in 15beta1 when filtering subquery including row_number window function - Mailing list pgsql-bugs

From Tom Lane
Subject Re: BUG #17495: Regression in 15beta1 when filtering subquery including row_number window function
Date
Msg-id 2026718.1653518386@sss.pgh.pa.us
Whole thread Raw
In response to Re: BUG #17495: Regression in 15beta1 when filtering subquery including row_number window function  (David Rowley <dgrowleyml@gmail.com>)
Responses Re: BUG #17495: Regression in 15beta1 when filtering subquery including row_number window function
List pgsql-bugs
David Rowley <dgrowleyml@gmail.com> writes:
> Maybe a better fix is to add a new Bitmapset field to WindowClause and
> have find_window_run_conditions() record the attno in that field when
> it appends the new runCondition to the runCondition field.
> remove_unused_subquery_outputs() can just bms_add_members that field
> to attrs_used.  This just means having to add a field to WindowClause
> post-beta.  Is that going to be a problem?

It'd mean a forced initdb, which is not great, but unless 0ff20288e
gets reverted there'd be no additional impact on beta testers.

A bigger problem with what you describe is that I don't really think
the planner should be mucking with the input parse tree like that.
Can't we retain this information somewhere else instead, in storage
associated with the PlannerInfo?

            regards, tom lane



pgsql-bugs by date:

Previous
From: David Rowley
Date:
Subject: Re: BUG #17495: Regression in 15beta1 when filtering subquery including row_number window function
Next
From: jam paydavousi
Date:
Subject: Re: BUG #17498: Receive Failed: (error code 1) when importing any csv file from pgAdmin with no explanations