Robert Haas <robertmh...@gmail.com> writes:
> On Thu, Jan 11, 2018 at 6:11 PM, Tom Lane <t...@sss.pgh.pa.us> wrote:
>> So define it as an ordered-set aggregate, and just ignore the question
>> of whether you need to sort the input (which is something that we leave
>> to the aggregate function to do anyway). The syntax would be a little
>> weird/non-orthogonal, but you can blame the SQL committee for that.
> Or alternatively, don't define a final function at all, or define one
> that just serializes the transition state to JSON or whatever.
A third possibility, which preserves notational simplicity at some
cost, is just to define the aggregate as taking the additional
parameter(s) as regular aggregate inputs. The transition function
would simply remember the last (or first) values of those parameters
as part of the transition state, and the final function would use
them from there.
The costs of this are:
1. you'd evaluate the additional params again at each row. I think
this is probably not a big deal if they're just constants, but YMMV.
2. if the aggregate executes over zero input rows, you don't get an
opportunity to collect the extra params at all. This might be fatal,
but it could also be a nonissue, either because you know your
application never aggregates over no rows, or because the correct
answer would be NULL or some such regardless of the extra params.
So there's more than one way to do it ...
regards, tom lane
