Re: [PATCHES] array_accum aggregate - Mailing list pgsql-hackers

From Bruce Momjian
Subject Re: [PATCHES] array_accum aggregate
Date
Msg-id 200702140042.l1E0gu605012@momjian.us
Whole thread Raw
In response to Re: [PATCHES] array_accum aggregate  (Stephen Frost <sfrost@snowman.net>)
List pgsql-hackers
What is the status of this feature addition?

---------------------------------------------------------------------------

Stephen Frost wrote:
-- Start of PGP signed section.
> * Tom Lane (tgl@sss.pgh.pa.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
-- End of PGP section, PGP failed!

--
  Bruce Momjian  <bruce@momjian.us>          http://momjian.us
  EnterpriseDB                               http://www.enterprisedb.com

  + If your life is a hard drive, Christ can be your backup. +

pgsql-hackers by date:

Previous
From: Stephen Frost
Date:
Subject: Re: Fixing insecure security definer functions
Next
From: Tom Lane
Date:
Subject: Re: Fixing insecure security definer functions