Re: Re: Request for Patch Feedback: Lag & Lead Window Functions Can Ignore Nulls

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>
Cc: Nicholas White <n(dot)j(dot)white(at)gmail(dot)com>, Peter Eisentraut <peter_e(at)gmx(dot)net>, Jeff Davis <pgsql(at)j-davis(dot)com>, Dean Rasheed <dean(dot)a(dot)rasheed(at)gmail(dot)com>, Troels Nielsen <bn(dot)troels(at)gmail(dot)com>, Hitoshi Harada <umi(dot)tanuki(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Re: Request for Patch Feedback: Lag & Lead Window Functions Can Ignore Nulls
Date: 2013-09-27 11:12:21
Message-ID: CA+TgmobkYBxF+BHXRgayhV6_Q1nxMdUr8f_WdH2w+JN2EXV=WA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, Sep 26, 2013 at 4:20 PM, Alvaro Herrera
<alvherre(at)2ndquadrant(dot)com> wrote:
> But how do we ensure that the BMS is allocated in a context? You'd have
> to switch contexts each time you call bms_add_member. I don't have a
> good answer to this.

The coding of bms_add_member is pretty funky. Why doesn't it just
repalloc() the input argument if it's not big enough? If it did that,
the new allocation would be in the same memory context as the original
one, and we'd not need to care about the memory context when adding an
element to an already non-empty set.

But even if we did decide to switch memory contexts on every call, it
would still be much cleaner than this. It's only three lines of code
(and about as many instructions) to save and restore
CurrentMemoryContext.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2013-09-27 12:36:21 Re: INSERT...ON DUPLICATE KEY LOCK FOR UPDATE
Previous Message Robert Haas 2013-09-27 11:01:28 Re: Extra functionality to createuser