Skip site navigation (1) Skip section navigation (2)

Re: array_accum aggregate

From: Stephen Frost <sfrost(at)snowman(dot)net>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-hackers(at)postgresql(dot)org, Neil Conway <neilc(at)samurai(dot)com>,pgsql-patches(at)postgresql(dot)org, Joe Conway <mail(at)joeconway(dot)com>
Subject: Re: array_accum aggregate
Date: 2006-10-12 20:28:41
Message-ID: 20061012202841.GH24675@kenobi.snowman.net (view raw or flat)
Thread:
Lists: pgsql-hackerspgsql-patches
* Tom Lane (tgl(at)sss(dot)pgh(dot)pa(dot)us) wrote:
> (However, now that we support nulls in arrays, meseems a more consistent
> definition would be that it allows null inputs and just includes them in
> the output.  So probably you do need it non-strict.)

This was my intention.

> I'm inclined to think that this example demonstrates a deficiency in the
> aggregate-function design: there should be a way to declare what we're
> really doing.  But I don't know exactly what that should look like.

I agree and would much rather have a clean solution which works with the
design than one which has to work outside it.  When I first was trying
to decide on the state-type I was looking through the PG catalogs for
essentially a "complex C type" which translated to a void*.  Perhaps
such a type could be added.  Unless that's considered along the lines of
an 'any' type it'd cause problems for the polymorphism aspect.  

Another alternative would be to provide a seperate area for each 
aggregate to put any other information it needs.  This would almost
certainly only be available to C functions but would essentially be a
void* which is provided through the AggState structure but tracked by
the aggregator routines and reset for each aggregate function being 
run.  If that's acceptable, I don't think it'd be all that difficult to
implement.  With that, aaccum_sfunc and aaccum_ffunc would ignore the 
state variable passed to them in favor of their custom structure 
available through fcinfo->AggState (I expect they'd just keep the 
state variable NULL and be marked non-strict, or set it to some constant
if necessary).  The pointer would have to be tracked somewhere and then
copied in/out on each call, but that doesn't seem too difficult to me.
After all, the state variable is already being tracked somewhere, this
would just sit next to it, in my head anyway.

I've got some time this weekend and would be happy to take a shot at
the second proposal if that's generally acceptable.

	Thanks,

		Stephen

In response to

Responses

pgsql-hackers by date

Next:From: Jim C. NasbyDate: 2006-10-12 20:30:23
Subject: ./configure argument checking
Previous:From: Jim C. NasbyDate: 2006-10-12 20:22:56
Subject: Re: more anti-postgresql FUD

pgsql-patches by date

Next:From: Tom LaneDate: 2006-10-12 22:45:22
Subject: Re: array_accum aggregate
Previous:From: Neil ConwayDate: 2006-10-12 19:16:18
Subject: Re: [PATCHES] Documentation fix for --with-ldap

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group