What is the status of this feature addition?


Stephen Frost wrote:
-- Start of PGP signed section.
> * Tom Lane ([EMAIL PROTECTED]) 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  <[EMAIL PROTECTED]>          http://momjian.us
  EnterpriseDB                               http://www.enterprisedb.com

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

---------------------------(end of broadcast)---------------------------
TIP 3: Have you checked our extensive FAQ?


Reply via email to