Fix missed copying of groupDistinct in transformPLAssignStmt.
authorTom Lane <tgl@sss.pgh.pa.us>
Sat, 27 Sep 2025 18:29:41 +0000 (14:29 -0400)
committerTom Lane <tgl@sss.pgh.pa.us>
Sat, 27 Sep 2025 18:29:41 +0000 (14:29 -0400)
Because we failed to do this, DISTINCT in GROUP BY DISTINCT would be
ignored in PL/pgSQL assignment statements.  It's not surprising that
no one noticed, since such statements will throw an error if the query
produces more than one row.  That eliminates most scenarios where
advanced forms of GROUP BY could be useful, and indeed makes it hard
even to find a simple test case.  Nonetheless it's wrong.

This is directly the fault of be45be9c3 which added the groupDistinct
field, but I think much of the blame has to fall on c9d529848, in
which I incautiously supposed that we'd manage to keep two copies of
a big chunk of parse-analysis logic in sync.  As a follow-up, I plan
to refactor so that there's only one copy.  But that seems useful
only in master, so let's use this one-line fix for the back branches.

Author: Tom Lane <tgl@sss.pgh.pa.us>
Discussion: https://postgr.es/m/31027.1758919078@sss.pgh.pa.us
Backpatch-through: 14

src/backend/parser/analyze.c

index aad46fe8e5cd9819f978cdeda7e60542a451bf77..41df73d5df8ddb3e18acbe71aa76f264af29e515 100644 (file)
@@ -2785,6 +2785,7 @@ transformPLAssignStmt(ParseState *pstate, PLAssignStmt *stmt)
                                            qry->sortClause,
                                            EXPR_KIND_GROUP_BY,
                                            false /* allow SQL92 rules */ );
+   qry->groupDistinct = sstmt->groupDistinct;
 
    if (sstmt->distinctClause == NIL)
    {