Re: [POC] Allow flattening of subquery with a link to upper query - Mailing list pgsql-hackers

From Andrey Lepikhov
Subject Re: [POC] Allow flattening of subquery with a link to upper query
Date
Msg-id 544c2280-7e02-461a-3d0c-7ae03ba462f2@postgrespro.ru
Whole thread Raw
In response to Re: [POC] Allow flattening of subquery with a link to upper query  (Richard Guo <guofenglinux@gmail.com>)
Responses Re: [POC] Allow flattening of subquery with a link to upper query
List pgsql-hackers
On 9/1/22 17:24, Richard Guo wrote:
> 
> On Wed, Aug 31, 2022 at 2:35 PM Andrey Lepikhov 
> <a.lepikhov@postgrespro.ru <mailto:a.lepikhov@postgrespro.ru>> wrote:
> 
>     Before flattening procedure we just look through the quals of subquery,
>     pull to the upper level OpExpr's containing variables from the upper
>     relation and replace their positions in the quals with true expression.
>     Further, the flattening machinery works as usual.
> 
> Hmm, I'm not sure this patch works correctly in all cases. It seems to
> me this patch pulls up the subquery without checking the constraints
> imposed by lateral references. If its quals contain any lateral
> references to rels outside a higher outer join, we would need to
> postpone quals from below an outer join to above it, which is probably
> incorrect.Yeah, it's not easy-to-solve problem. If I correctly understand the 
code, to fix this problem we must implement the same logic, as 
pull_up_subqueries (lowest_outer_join/safe_upper_varnos). It looks ugly. 
But, more important, does this feature deserve such efforts/changes?

-- 
Regards
Andrey Lepikhov
Postgres Professional




pgsql-hackers by date:

Previous
From: "kuroda.hayato@fujitsu.com"
Date:
Subject: RE: test_decoding assertion failure for the loss of top-sub transaction relationship
Next
From: Justin Pryzby
Date:
Subject: Re: Different compression methods for FPI