From: Tom Lane <tgl@sss.pgh.pa.us>
To: "David G. Johnston" <david.g.johnston@gmail.com>
cc: Adrian Klaver <adrian.klaver@aklaver.com>,
        PALAYRET Jacques <jacques.palayret@meteo.fr>,
        pgsql-general@lists.postgresql.org
Subject: Re: PostgreSQL query with FULL OUTER JOIN and subquery using column of GROUP BY expression ERROR: subquery uses ungrouped column from outer query
In-reply-to: <CAKFQuwY27TZSERWdmC+=RO+B86KAOSW+CeJSSL52eUZQLYZsrA@mail.gmail.com>
References: <970600119.344834366.1772018068349.JavaMail.zimbra@meteo.fr> <52acd108-2949-4762-80c2-c761662fde73@aklaver.com> <CAKFQuwY27TZSERWdmC+=RO+B86KAOSW+CeJSSL52eUZQLYZsrA@mail.gmail.com>
Comments: In-reply-to "David G. Johnston" <david.g.johnston@gmail.com>
	message dated "Wed, 25 Feb 2026 09:20:18 -0700"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <295607.1772040819.1@sss.pgh.pa.us>
Date: Wed, 25 Feb 2026 12:33:39 -0500
Message-ID: <295608.1772040819@sss.pgh.pa.us>
Archived-At: <https://www.postgresql.org/message-id/295608.1772040819%40sss.pgh.pa.us>
Precedence: bulk

"David G. Johnston" <david.g.johnston@gmail.com> writes:
> My first impression is that this is a bug.  Especially since the query
> apparently executes in both left-join and right-join modes.

Well, it's a longstanding deficiency anyway.  The problem is that
the full-join-using merged column "id" is represented as
"COALESCE(t2.id, t3.id)" not as a single Var.  That should be okay,
because we can handle grouping by an expression, but
substitute_grouped_columns (and check_ungrouped_columns before it)
doesn't handle the case in subqueries:

 * NOTE: we recognize grouping expressions in the main query, but only
 * grouping Vars in subqueries.  For example, this will be rejected,
 * although it could be allowed:
 *		SELECT
 *			(SELECT x FROM bar where y = (foo.a + foo.b))
 *		FROM foo
 *		GROUP BY a + b;
 * The difficulty is the need to account for different sublevels_up.
 * This appears to require a whole custom version of equal(), which is
 * way more pain than the feature seems worth.

This commentary dates to 2003 (and it's from a patch that replaced an
older implementation with the same limitation; it doesn't look to me
like the case ever worked).  AFAIR, the number of complaints we've
gotten about this limitation in the past 30 years could be counted
without running out of thumbs.

Still, it is annoying.  I wonder if there's a way to do it without
either a large amount of new code or exponential time spent
trying useless subexpression matches...

			regards, tom lane