On Fri, Dec 26, 2008 at 02:17:29PM -0500, Tom Lane wrote:
> So the alternatives I see are:
>
> 1. Go back to Hitoshi's plan of passing WindowAggState to the
> aggregates. This will require changing every one of the ten aggregates
> in the core distro, as well as every third-party aggregate that has
> a similar optimization; and we just have to keep our fingers crossed
> that anyone who's taking a short-cut will fix their code before it
> fails in the field.
>
> 2. Use an intermediate dummy AggState as I have in my version, but
> document some convention for telling this from a "real" AggState
> when needed. (Not hard, we just pick some field that would never be
> zero in a real AggState and document testing that.) This is certainly
> on the ugly side, but it would very substantially cut the number of
> places that need changes. Only aggregates that are doing something
> irreversible in their final-functions would need to be touched.
>
> If we were working in a green field then #1 would clearly be the
> preferable choice, but worrying about compatibility with existing
> third-party aggregates is making me lean to #2. Comments?
Exactly how large is this third-party aggregate problem? Rather than
support a huge wart, we could just tell people starting now and
prominently in the release notes that such things need a re-do and
point to examples of how it's done.
The case this won't work for is where a vendor of a proprietary C
extension is gone and/or won't update their stuff for 8.4, and it
seems to me that we can't, and shouldn't try to, take responsibility
for that use case anyhow.
Cheers,
David.
--
David Fetter <david@fetter.org> http://fetter.org/
Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter
Skype: davidfetter XMPP: david.fetter@gmail.com
Remember to vote!
Consider donating to Postgres: http://www.postgresql.org/about/donate