From: Andrew Gierth <andrew@tao11.riddles.org.uk>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Michael Paquier <michael@paquier.xyz>,  cyg0810@gmail.com,
  pgsql-bugs@lists.postgresql.org
Subject: Re: BUG #17088: FailedAssertion in prepagg.c
In-Reply-To: <1908212.1625690962@sss.pgh.pa.us> (Tom Lane's message of "Wed,
	07 Jul 2021 16:49:22 -0400")
Message-ID: <87a6mxrggq.fsf@news-spur.riddles.org.uk>
References: <17088-e33882b387de7f5c@postgresql.org>
	<YOWJQTovI//DNe8/@paquier.xyz> <1908212.1625690962@sss.pgh.pa.us>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.3 (berkeley-unix)
Date: Wed, 07 Jul 2021 22:18:01 +0100
MIME-Version: 1.0
Content-Type: text/plain
Archived-At: 
 <https://www.postgresql.org/message-id/87a6mxrggq.fsf%40news-spur.riddles.org.uk>
Precedence: bulk

>>>>> "Tom" == Tom Lane <tgl@sss.pgh.pa.us> writes:

 Tom> An alternative theory is that we should never have done anything
 Tom> at all to the argument tree of a GroupingFunc. Since it's not
 Tom> supposed to be evaluated, treating it as a target for expression
 Tom> preprocessing might be a mistake altogether. I wonder why its
 Tom> arguments aren't stored as sortgroupref indexes or the like.

The arguments are stored as sortgrouprefs (the "refs" list) for actual
use; the "args" list is only kept for the benefit of EXPLAIN and
deparsing.

A number of places in the planner have to explicitly avoid recursing
into GroupingFunc->args when walking trees specifically because they are
not evaluated. It looks to me like some places where that should have
been checked for were missed. Looking into it.

-- 
Andrew (irc:RhodiumToad)