Re: Re: Request for Patch Feedback: Lag & Lead Window Functions Can Ignore Nulls
От | Heikki Linnakangas |
---|---|
Тема | Re: Re: Request for Patch Feedback: Lag & Lead Window Functions Can Ignore Nulls |
Дата | |
Msg-id | 5245E2F3.7040409@vmware.com обсуждение исходный текст |
Ответ на | Re: Re: Request for Patch Feedback: Lag & Lead Window Functions Can Ignore Nulls (Robert Haas <robertmhaas@gmail.com>) |
Ответы |
Re: Re: Request for Patch Feedback: Lag & Lead Window
Functions Can Ignore Nulls
|
Список | pgsql-hackers |
On 27.09.2013 14:12, Robert Haas wrote: > On Thu, Sep 26, 2013 at 4:20 PM, Alvaro Herrera > <alvherre@2ndquadrant.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. [looks] Huh, yeah, as it stands, bms_add_member() is an accident waiting to happen. It's totally non-obvious that it might cause the BMS to jump from another memory context to CurrentMemoryContext. Same with bms_add_members(). And it would be good to Assert in bms_join that both arguments are in the same from MemoryContext. Let's fix that... - Heikki
В списке pgsql-hackers по дате отправления: