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

Re: [HACKERS] array_accum aggregate

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, Martijn van Oosterhout <kleptog(at)svana(dot)org>, Neil Conway <neilc(at)samurai(dot)com>, pgsql-patches(at)postgresql(dot)org, Joe Conway <mail(at)joeconway(dot)com>
Subject: Re: [HACKERS] array_accum aggregate
Date: 2006-10-13 17:06:17
Message-ID: 2864.1160759177@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-hackerspgsql-patches
Stephen Frost <sfrost(at)snowman(dot)net> writes:
>>> Additionally, we'd have to be
>>> able to mark the types as being polymorhpic along the same lines as
>>> anyelement/anyarray.
>>
>> What for?

> So that the finalfunc can be polymorphic along the lines of my suggested
> aaccum_sfunc(anyarray,anyelement) returns anyarray and
> aaccum_ffunc(anyarray) returns anyarray.

Hmm ... there's not any real need for this at the level of the
aggregate, because we resolve a polymorphic aggregate's output type
directly from its input type(s), and we've already established that the
general-purpose agg code doesn't need to be able to infer anything about
the transition data type.  However the function code is going to
complain if you try to declare "my_sfunc(aggregate_state) returns
anyarray" because that looks ill-formed ... and indeed that kinda kills
the idea of being able to call my_sfunc standalone anyway.

Maybe we need a more radical solution in which the sfunc/ffunc don't
exist as separately callable entities at all.  That would sidestep the
whole need to have a type-system representation for the state data,
as well as eliminate worries about whether we've sufficiently plugged
the security risks of being able to call one of them in an unexpected
context.  Not sure what this should look like in the catalogs though.

			regards, tom lane

In response to

pgsql-hackers by date

Next:From: Jim C. NasbyDate: 2006-10-13 17:07:14
Subject: Re: ./configure argument checking
Previous:From: Martijn van OosterhoutDate: 2006-10-13 17:03:41
Subject: Re: more anti-postgresql FUD

pgsql-patches by date

Next:From: Kai-Uwe SattlerDate: 2006-10-13 18:49:05
Subject: index advisor
Previous:From: Stephen FrostDate: 2006-10-13 16:44:25
Subject: Re: [HACKERS] array_accum aggregate

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