Re: Wrong results from a parameterized Append

Hi,

On Fri Oct 9, 2026 at 4:13 PM -03, Tom Lane wrote:
> Here's a v2 patch incorporating the cosmetic changes I suggested,
> and substantially enlarging the comments around the area.
> I don't think we're ready to commit though, because I see a number
> of loose ends.
>

I've spent some time testing v2 with some planner GUC combinations
(hashjoin/mergejoin/material/ memoize off, collapse limits = 1,
partitionwise join, seqscan off...) and on master it returned wrong
results, and all of them had a Materialize on top of a parameterized
Append, as Richard described. With v2 all of them return the right
results, and the only plan change on those is the join filter coming
back. I didn't find any other wrong results with v2.

Just a small comment: Since Shihao's LATERAL case also fails on v16,
perhaps it's worth adding it to the regression tests too, so we have a
test that fails on all the back branches.

I also checked the back branches. v2 does not apply cleanly on 18, 17
and 16. On those branches only Material, Memoize, Unique and
GroupingSets paths copy the subpath's param_info, since the others
started doing that with 24225ad9aaf in v19. I think that on 17 and 16
there are two more differences: get_memoize_path() doesn't read
ppi_serials, and get_param_path_clause_serials() still has to handle
parameterized MergeAppend paths, which were only removed in 18.

--
Matheus Alcantara
EDB: https://www.enterprisedb.com