Re: WITHIN GROUP patch
От | Andrew Gierth |
---|---|
Тема | Re: WITHIN GROUP patch |
Дата | |
Msg-id | 87eh5sibt1.fsf@news-spur.riddles.org.uk обсуждение исходный текст |
Ответ на | Re: WITHIN GROUP patch (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: WITHIN GROUP patch
|
Список | pgsql-hackers |
>>>>> "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)
В списке pgsql-hackers по дате отправления: