On 27 July 2015 at 20:11, Heikki Linnakangas <hlinn...@iki.fi> wrote:
> On 07/27/2015 08:34 AM, David Rowley wrote: > > In this function I also wasn't quite sure if it was with comparing both >> non-NULL INITCOND's here. I believe my code comments may slightly >> contradict what the code actually does, as the comments talk about them >> having to match, but the code just bails if any are non-NULL. The reason I >> didn't check them was because it seems inevitable that some duplicate work >> needs to be done when setting up the INITCOND. Perhaps it's worth it? >> > > It would be nice to handle non-NULL initconds. I think you'll have to > check that the input function isn't volatile. Or perhaps just call the > input function, and check that the resulting Datum is byte-per-byte > identical, although that might be awkward to do with the current code > structure. > > Yeah, it's awkward, as I just managed to remind myself: The aggtranstype needs to be known before we can call GetAggInitVal() on the initval datum. That currently happens in build_transstate_for_aggref() only when we've decided to create a new state. transstate->initValue = GetAggInitVal(textInitVal, transstate->aggtranstype); And to get the aggtranstype: transstate->aggtranstype = resolve_aggregate_transtype(aggref->aggfnoid, aggform->aggtranstype, inputTypes, numArguments); Of course, not impossible, but lots of code gets duplicated. Regards David Rowley -- David Rowley http://www.2ndQuadrant.com/ <http://www.2ndquadrant.com/> PostgreSQL Development, 24x7 Support, Training & Services
