| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Stephen Frost <sfrost(at)snowman(dot)net> |
| Cc: | pgsql-hackers(at)postgresql(dot)org |
| Subject: | Re: array_accum aggregate |
| Date: | 2006-10-07 03:39:19 |
| Message-ID: | 13184.1160192359@sss.pgh.pa.us |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Stephen Frost <sfrost(at)snowman(dot)net> writes:
> * Tom Lane (tgl(at)sss(dot)pgh(dot)pa(dot)us) wrote:
>> It looks like it should work to have just one polymorphic aggregate
>> definition, eg, array_accum(anyelement) returns anyarray.
> I was hoping to do that, but since it's an aggregate the ffunc format is
> pre-defined to require accepting the 'internal state' and nothing else,
> and to return 'anyelement' or 'anyarray' one of the inputs must be an
> 'anyelement' or 'anyarray', aiui.
Hmm ... I hadn't been thinking about what the state type would need to
be, but certainly "bytea" is a lie given what you're really doing.
We've run into this same problem in contrib/intagg: sometimes you'd like
to use a state data structure that isn't any regular SQL datatype, and
in particular isn't just a single blob of memory. That's a problem from
nodeAgg's point of view because it expects to be responsible for copying
the state value from one context to another. Don't have an immediate
idea for a solution ...
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Sergey E. Koposov | 2006-10-07 14:01:44 | FailedAssertion() in 8.2beta1 |
| Previous Message | Bruce Momjian | 2006-10-07 03:21:42 | Added links to the release notes |