Re: array_accum aggregate

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: pgsql-hackers(at)postgresql(dot)org, Stephen Frost <sfrost(at)snowman(dot)net>
Cc: 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 22:58:52
Message-ID: 20443.1160693932@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers pgsql-patches

I wrote:
> aggregate_state would have no other uses in the system, and its input
> and output functions would raise an error, so type safety is assured
> --- there would be no way to call either the sfunc or ffunc "manually",
> except by passing a NULL value, which should be safe because that's what
> they'd expect as the aggregate initial condition.

Um, no, I take that back, unless you want to invent a separate
pseudotype for each such aggregate. Otherwise you can crash it with

my_ffunc(your_sfunc(null, whatever))

because my_ffunc will be expecting a datastructure different from what
it gets.

Maybe having a check for AggState call context is enough of a defense for
that, but I'm not really satisfied. Back to the drawing board ...

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Bruce Momjian 2006-10-12 23:18:41 Re: [COMMITTERS] pgsql: Stamp 7.3.16.
Previous Message Tom Lane 2006-10-12 22:50:55 Re: [COMMITTERS] pgsql: Stamp 7.3.16.

Browse pgsql-patches by date

  From Date Subject
Next Message Martijn van Oosterhout 2006-10-13 08:05:57 Re: [HACKERS] array_accum aggregate
Previous Message Tom Lane 2006-10-12 22:45:22 Re: array_accum aggregate