Re: Aggregate transition state merging vs. hypothetical set functions

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Heikki Linnakangas <hlinnaka(at)iki(dot)fi>
Cc: David Rowley <david(dot)rowley(at)2ndquadrant(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Aggregate transition state merging vs. hypothetical set functions
Date: 2017-10-13 23:01:18
Message-ID: 7410.1507935678@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

I wrote:
> Moving on to the exact color of the bikeshed: it seems like the right
> way to present this to users of CREATE AGGREGATE is in terms of "does
> the final function modify the transition state?". So maybe the values
> could be spelled
> SMODIFY = READ_ONLY ffunc never touches state, ok as window agg
> SMODIFY = SHARABLE ffunc does some one-time change like sorting,
> so state merging is OK but not window agg
> SMODIFY = READ_WRITE ffunc trashes state, can't do merging either
> I'm not set on these names by any means; anyone have a better idea?

After contemplating the existing CREATE AGGREGATE parameters, particularly
[M]FINALFUNC_EXTRA, it seemed to me that better nomenclature is

[M]FINALFUNC_MODIFY = READ_ONLY
[M]FINALFUNC_MODIFY = STOP_UPDATES
[M]FINALFUNC_MODIFY = READ_WRITE

where "stop updates" is intended to imply "you can't call the transfn
anymore after the first finalfn call". I'm still not that much in
love with that terminology, but don't have a better idea now.

Attached is a WIP patch; I believe it's code-complete but the SGML
docs are lacking. Barring objections I'll finish up the docs and
push this.

regards, tom lane

Attachment Content-Type Size
mark-aggregate-finalfn-safety-explicitly.patch text/x-diff 81.7 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Thomas Munro 2017-10-13 23:14:36 Re: Continuous integration on Windows?
Previous Message Gourav Kumar 2017-10-13 22:30:15 Re: Disable cross products in postgres