On Wed, Oct 29, 2014 at 12:04 PM, Kirk Roybal wrote:
> This [custom aggregate gapfill] is a pretty elegant way of getting there.
>
> It also does a better job of respecting the window frame.
>
> I'll use this until this
> https://commitfest.postgresql.org/action/patch_view?id=1096 shows up.
Yes.
This is a pretty elegant way of getting there.
It also does a better job of respecting the window frame.
I'll use this until this
https://commitfest.postgresql.org/action/patch_view?id=1096 [1] shows
up.
Thanks
On 2014-10-28 17:35, Merlin Moncure wrote:
> On Tue, Oct 28, 2014 at 12:40
This is cleaner and better.
Thanks for the link, I hope to see it in a commitfest some time soon.
/Kirk
On 2014-10-28 16:34, Vladimir Sitnikov wrote:
> There is already a patch for that (ignore/respect nulls in lead/lag):
> https://commitfest.postgresql.org/action/patch_view?id=1096 [1]
On Tue, Oct 28, 2014 at 12:40 PM, Kirk Roybal wrote:
> Hi Guys,
>
> I propose a lag (and/or lead) window function that propagates the last
> non-null value to the current row.
> Here's an example of what I mean by that:
>
> CREATE TABLE lag_test (id serial primary key, natural_key integer, somebod
There is already a patch for that (ignore/respect nulls in lead/lag):
https://commitfest.postgresql.org/action/patch_view?id=1096
--
Vladimir
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hack
Hi Guys,
I propose a lag (and/or lead) window function that propagates the last
non-null value to the current row.
Here's an example of what I mean by that:
CREATE TABLE lag_test (id serial primary key, natural_key integer,
somebody text);
INSERT INTO lag_test(natural_key, somebody)
VALUES
