Re: [HACKERS] [PATCHES] patch implementing the multi-argument aggregates (SOC project)
Tom Lane [EMAIL PROTECTED] writes: This patch is nowhere near ready for submission :-(. Most of the comments seem to be I don't know what to do here ... Just to be clear, I think what Tom's saying it's not ready to be *applied*. Sending patches to this list early and often during development is generally encouraged. -- Gregory Stark EnterpriseDB http://www.enterprisedb.com ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] [PATCHES] patch implementing the multi-argument aggregates (SOC project)
Gregory Stark [EMAIL PROTECTED] writes: Tom Lane [EMAIL PROTECTED] writes: This patch is nowhere near ready for submission :-(. Most of the comments seem to be I don't know what to do here ... Just to be clear, I think what Tom's saying it's not ready to be *applied*. Sending patches to this list early and often during development is generally encouraged. Indeed, but if that was the point we should have been seeing drafts of this patch long ago. I interpreted Sergey's submission as getting this in before feature freeze, and in that context the bar is higher. If a patch isn't pretty nearly ready to be applied when the freeze deadline arrives, we won't wait around for it. regards, tom lane ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] [PATCHES] patch implementing the multi-argument aggregates (SOC project)
Sergey E. Koposov [EMAIL PROTECTED] writes: Since the feature freeze is in a few days, I'm sending the first iteration of my patch implementing the multi-argument aggregates (PolyArgAgg) (SOC project) This patch is nowhere near ready for submission :-(. Most of the comments seem to be I don't know what to do here ... A general hint on the polymorphic stuff is that you should be able to exactly duplicate what's done for polymorphic functions --- or even better, get rid of the separate code for aggregates and just invoke the existing logic for functions. (You might need to refactor code a little bit to separate out the common functionality.) Instead of copying data inside advance_transition_function, it might be better for the caller to store the values into the right fields of a temporary FunctionCallInfoData struct, and just pass that to advance_transition_function. The names for the new aggregates seem a bit, how to say, terse and unfriendly. SQL generally tends to a more verbose style of naming. regards, tom lane ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
