On Sun, Apr 17, 2016 at 10:22:24AM -0400, Tom Lane wrote: > David Rowley <david.row...@2ndquadrant.com> writes: > > On 16 April 2016 at 04:27, Tom Lane <t...@sss.pgh.pa.us> wrote: > >> +1 for the latter, if we can do it conveniently. I think exposing > >> the names of the aggregate implementation functions would be very > >> user-unfriendly, as nobody but us hackers knows what those are. > > > It does not really seem all that convenient to do this. It also seems > > a bit strange to me to have a parent node report a column which does > > not exist in any nodes descending from it. Remember that the combine > > Aggref does not have the same ->args as its corresponding partial > > Aggref. It's not all that clear to me if there is any nice way to do > > have this work the way you'd like. If we were to just call > > get_rule_expr() on the first arg of the combine aggregate node, it > > would re-print the PARTIAL keyword again. > > This suggests to me that the parsetree representation for partial > aggregates was badly chosen. If EXPLAIN can't recognize them, then > neither can anything else, and we may soon find needs for telling > the difference that are not just cosmetic. Maybe we need more > fields in Aggref.
[This is a generic notification.] The above-described topic is currently a PostgreSQL 9.6 open item. Robert, since you committed the patch believed to have created it, you own this open item. If that responsibility lies elsewhere, please let us know whose responsibility it is to fix this. Since new open items may be discovered at any time and I want to plan to have them all fixed well in advance of the ship date, I will appreciate your efforts toward speedy resolution. Please present, within 72 hours, a plan to fix the defect within seven days of this message. Thanks. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
