From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | pgsql-hackers(at)postgresql(dot)org, "Sergey E(dot) Koposov" <math(at)sai(dot)msu(dot)ru> |
Cc: | pgsql-patches(at)postgresql(dot)org |
Subject: | Re: patch implementing the multi-argument aggregates (SOC project) |
Date: | 2006-07-24 14:49:17 |
Message-ID: | 10792.1153752557@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers pgsql-patches |
"Sergey E. Koposov" <math(at)sai(dot)msu(dot)ru> 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
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2006-07-24 14:52:49 | Re: pgstattuple extension for indexes |
Previous Message | Alvaro Herrera | 2006-07-24 14:26:28 | Re: pgstattuple extension for indexes |
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2006-07-24 14:52:49 | Re: pgstattuple extension for indexes |
Previous Message | Alvaro Herrera | 2006-07-24 14:26:28 | Re: pgstattuple extension for indexes |