From: | David Rowley <dgrowleyml(at)gmail(dot)com> |
---|---|
To: | Florian Pflug <fgp(at)phlo(dot)org> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Kevin Grittner <kgrittn(at)ymail(dot)com>, Dean Rasheed <dean(dot)a(dot)rasheed(at)gmail(dot)com>, Josh Berkus <josh(at)agliodbs(dot)com>, Greg Stark <stark(at)mit(dot)edu>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: [PATCH] Negative Transition Aggregate Functions (WIP) |
Date: | 2014-01-17 19:34:41 |
Message-ID: | CAApHDvqieH2=BywtP-J6HHbcruZh1Jo-n0_U_hGC-M=EZ7wrWQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Fri, Jan 17, 2014 at 3:05 PM, Florian Pflug <fgp(at)phlo(dot)org> wrote:
>
> I've now shuffled things around so that we can use inverse transition
> functions
> even if only some aggregates provide them, and to allow inverse transition
> functions to force a restart by returning NULL. The rules regarding NULL
> handling
> are now the following
>
>
Maybe this is me thinking out loud, but I'm just thinking about the numeric
case again.
Since the patch can now handle inverse transition functions returning NULL
when they fail to perform inverse transitions, I'm wondering if we could
add an "expectedscale" to NumericAggState, set it to -1 initially, when we
get the first value set the expectedscale to the dscale of that numeric,
then if we get anything but that value we'll set the expectedscale back to
-1 again, if we are asked to perform an inverse transition with a
expectedscale as -1 we'll return null, otherwise we can perform the inverse
transition...
Thoughts?
Regards
David Rowley
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2014-01-17 19:36:25 | Re: [HACKERS] surprising to_timestamp behavior |
Previous Message | Gregory Smith | 2014-01-17 19:27:50 | Re: [v9.4] row level security |