>>>>> "Tom" == Tom Lane <tgl@sss.pgh.pa.us> writes:
Tom> Well, sure, but I was only suggesting adding it when theTom> aggregate asks for it, probably via a new flag column
inTom>pg_aggregate.
Sure, I was only pointing out the necessity.
Tom> The question you're evading is what additional functionalityTom> could be had if the aggregate could demand a
differentdatatypeTom> or constant value for the flag column.
I don't really see a question there to answer - I simply chose to
provide a general mechanism rather than make assumptions about what
future users of the code would desire. I have no specific application
in mind that would require some other type.
>> Adding it only for hypothetical set functions is making a>> distinction in how functions are executed that I don't
thinkis>> warranted -
Tom> That seems like rather a curious argument from someone who'sTom> willing to give up the ability to specify a
regulartransitionTom> value concurrently with the flag column.
In the current patch the idea of also specifying a regular transition
value is meaningless since there is no transition function.
Tom> But anyway, what I'm thinking right now is that these questionsTom> would all go away if the aggregate
transfunctionwere receivingTom> the rows and sticking them into the tuplestore. It could addTom> whatever columns it
feltlike.
True, but this ends up duplicating the sorting functionality of
nodeAgg that we are leveraging off in the first place. I think this
will be somewhat more intrusive and likely slower.
--
Andrew (irc:RhodiumToad)