Re: BUG #18077: PostgreSQL server subprocess crashed by a SELECT statement with WITH clause

On Sat, Sep 2, 2023 at 4:41 AM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:

> Richard Guo <guofenglinux(at)gmail(dot)com> writes:
> > On Wed, Aug 30, 2023 at 7:42 PM Richard Guo <guofenglinux(at)gmail(dot)com>
> wrote:
> >> When we expand Var 'c1' from func(c1), we figure out that it comes from
> >> subquery 's'. When we recurse into subquery 's', we just build an
> >> additional level of ParseState atop the current ParseState, which seems
> >> not correct. Shouldn't we climb up by the nesting depth first before we
> >> build the additional level of ParseState? Something like
> >> ...
>
> > Here is the patch.
>
> Yeah, I think your diagnosis is correct. The existing regression tests
> reach this code path, but not with netlevelsup different from zero.
> I noted from the code coverage report that the same is true of the
> nearby RTE_CTE code path: that does have a loop to crawl up the pstate
> stack, but it isn't getting iterated. The attached improved patch
> extends the test case so it also covers that.

+1 to the v2 patch.

BTW, do you think get_name_for_var_field() has similar problem for
RTE_SUBQUERY case? The RTE_CTE code path in that function crawls up the
namespace stack before recursing into the CTE while the RTE_SUBQUERY
code patch does not, which looks like an oversight. I tried to find a
test case to show it's indeed a problem but with no luck.

Thanks
Richard