Feedback-ID: ia2694551:Fastmail
Date: Tue, 2 May 2023 19:54:09 +0200
From: Alvaro Herrera <alvherre@alvh.no-ip.org>
To: Amit Langote <amitlangote09@gmail.com>
Cc: Tom Lane <tgl@sss.pgh.pa.us>,
	Pg Hackers <pgsql-hackers@lists.postgresql.org>
Subject: Re: "variable not found in subplan target list"
Message-ID: <20230502175409.kcoirxczpdha26wt@alvherre.pgsql>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <20230330105325.y6uvpalspynf2frt@alvherre.pgsql>
Archived-At: 
 <https://www.postgresql.org/message-id/20230502175409.kcoirxczpdha26wt%40alvherre.pgsql>
Precedence: bulk

Hi Amit,

On 2023-Mar-30, Alvaro Herrera wrote:

> On 2023-Mar-29, Amit Langote wrote:

> > Though, I wonder if we need to keep ec386948948 that introduced the
> > notion of part_prune_index around if the project that needed it [1]
> > has moved on to an entirely different approach altogether, one that
> > doesn't require hacking up the pruning code.
> 
> Hmm, that's indeed tempting.

We have an open item about this, and I see no reason not to do it.  I
checked, and putting things back is just a matter of reverting
589bb816499e and ec386948948, cleaning up some trivial pgindent-induced
conflicts, and bumping catversion once more.  Would you like to do that
yourself, or do you prefer that I do it?  Ideally, we'd do it before
beta1.

-- 
Álvaro Herrera        Breisgau, Deutschland  —  https://www.EnterpriseDB.com/