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. > Note that I've done nothing for the weird schema prefixing problem I > mentioned. I think I'd need input on the best way to solve this. If > it's actually a problem. It sure looks like a problem to me. Maybe it's only cosmetic, but it's going to cause confusion and bug reports. EXPLAIN output for parallel queries is going to be confusing enough anyway; we need to avoid having artifacts like this. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers