On 30 May 2016 at 15:44, Andrew Gierth wrote:
>> "Dean" == Dean Rasheed writes:
>
> Dean> That may be so, but we already support FILTER for all windows
> Dean> functions as well as aggregates:
>
> Not so:
>
> "If FILTER is specified, then only the input rows for which the
> filter_clause ev
> "Dean" == Dean Rasheed writes:
Dean> That may be so, but we already support FILTER for all windows
Dean> functions as well as aggregates:
Not so:
"If FILTER is specified, then only the input rows for which the
filter_clause evaluates to true are fed to the window function; other
rows ar
On 23 May 2016 at 17:01, Jeff Davis wrote:
> On Fri, May 20, 2016 at 1:41 PM, David G. Johnston
> wrote:
>> How does the relatively new FILTER clause play into this, if at all?
>
> My interpretation of the standard is that FILTER is not allowable for
> a window function, and IGNORE|RESPECT NULLS
> My interpretation of the standard is that FILTER is not allowable for
> a window function, and IGNORE|RESPECT NULLS is not allowable for an
> ordinary aggregate.
Yes, it is clear.
> So if we support IGNORE|RESPECT NULLS for anything other than a window
> function, we have to come up with our ow
On Mon, May 23, 2016 at 12:01 PM, Jeff Davis wrote:
> On Fri, May 20, 2016 at 1:41 PM, David G. Johnston
> wrote:
> > How does the relatively new FILTER clause play into this, if at all?
>
> My interpretation of the standard is that FILTER is not allowable for
> a window function, and IGNORE|RES
On Fri, May 20, 2016 at 1:41 PM, David G. Johnston
wrote:
> How does the relatively new FILTER clause play into this, if at all?
My interpretation of the standard is that FILTER is not allowable for
a window function, and IGNORE|RESPECT NULLS is not allowable for an
ordinary aggregate.
So if we
Just doing a drive-by...
On Fri, May 20, 2016 at 3:50 PM, Jeff Davis wrote:
> Old thread link:
>
> http://www.postgresql.org/message-id/CA+=vxna5_n1q5q5okxc0aqnndbo2ru6gvw+86wk+onsunjd...@mail.gmail.com
>
> On Thu, Apr 14, 2016 at 1:29 PM, Stephen Frost wrote:
> > Jeff
> >
> > (Reviving an old
Old thread link:
http://www.postgresql.org/message-id/CA+=vxna5_n1q5q5okxc0aqnndbo2ru6gvw+86wk+onsunjd...@mail.gmail.com
On Thu, Apr 14, 2016 at 1:29 PM, Stephen Frost wrote:
> Jeff
>
> (Reviving an old thread for 2014...)
>
> Would you have time to work on this for 9.7..? I came across a
> real
Jeff
(Reviving an old thread for 2014...)
* Jeff Davis (pg...@j-davis.com) wrote:
> On Thu, 2014-07-10 at 23:43 -0700, Jeff Davis wrote:
> > On Mon, 2014-07-07 at 01:21 -0700, Jeff Davis wrote:
> > > On Sun, 2014-07-06 at 21:11 -0700, Jeff Davis wrote:
> > > > On Wed, 2014-04-16 at 12:50 +0100, N
Hi Abhijit -
> What's the status of this patch?
The latest version of the patch needs a review, and I'd like to get it
committed in this CF if possible. Thanks -
Nick
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgre
Hi.
What's the status of this patch? Jeff, Álvaro, you're listed as
reviewers. Have you had a chance to look at the updated version
that Nick posted?
-- Abhijit
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org
We have this block:
+ {
+ /*
+* This is the window we want - but we have to tweak the
+* definition slightly (e.g. to support the IGNORE NULLS frame
+* option) as we're not using the default (i.e. parent) frame
+* options.
+
Nicholas White escribió:
> > But even if we did decide to switch memory contexts on every call, it would
> > still be much cleaner than this.
>
> I've removed all the bms_initalize code from the patch and am using
> this solution. As the partition memory is zero-initialised I just
> store a Bitm
On 29.09.2013 23:32, Nicholas White wrote:
bms_add_member() is an accident waiting to happen
I've attached a patch that makes it use repalloc as suggested
You'll have to zero out the extended portion.
I tried to demonstrate that by setting RANDOMIZE_ALLOCATED_MEMORY, but
surprisingly regres
> bms_add_member() is an accident waiting to happen
I've attached a patch that makes it use repalloc as suggested - is it
OK to commit separately? I'll address the lead-lag patch comments in
the next couple of days. Thanks -
repalloc.patch
Description: Binary data
--
Sent via pgsql-hackers mai
On 27.09.2013 14:12, Robert Haas wrote:
On Thu, Sep 26, 2013 at 4:20 PM, Alvaro Herrera
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 p
On Thu, Sep 26, 2013 at 4:20 PM, Alvaro Herrera
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
repal
I gave this a quick look. It took me a while to figure out how to apply
it -- turns out you used the "ignore whitespace" option to diff, so the
only way to apply it was with patch -p1 --ignore-whitespace. Please
don't do that.
I ran pgindent over the patched code and there were a number of chang
> Please fix these compiler warnings
Fixed - see attached. Thanks -
lead-lag-ignore-nulls.patch
Description: Binary data
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Wed, 2013-08-21 at 22:34 -0400, Nicholas White wrote:
> > but needs a rebase.
>
> See attached - thanks!
Please fix these compiler warnings:
windowfuncs.c: In function ‘leadlag_common’:
windowfuncs.c:366:3: warning: passing argument 1 of ‘bms_initialize’ from
incompatible pointer type [enabl
> but needs a rebase.
See attached - thanks!
lead-lag-ignore-nulls.patch
Description: Binary data
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Thu, 2013-07-11 at 10:51 -0400, Nicholas White wrote:
> I've attached a revised version that fixes the issues above:
This patch is in the 2013-09 commitfest but needs a rebase.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http:/
> (For that matter, am I not supposed to commit between 'fests? Or is it
> still an option for me to finish up with this after I get back even if
> we close the CF?)
The idea of the CommitFests is to give committers some *time off*
between them. If a committer wants to commit stuff when it's not
On 21.07.2013 08:41, Jeff Davis wrote:
(For that matter, am I not supposed to commit between 'fests? Or is it
still an option for me to finish up with this after I get back even if
we close the CF?)
It's totally OK to commit stuff between 'fests.
- Heikki
--
Sent via pgsql-hackers mailing li
On Fri, 2013-07-19 at 09:39 -0700, Josh Berkus wrote:
> So ... are you doing a final review of this for the CF, Jeff? We need
> to either commit it or bounce it to the next CF.
I am going on vacation tomorrow, and I just didn't quite find time to
take this to commit. Sorry about that, Nicholas. T
On 07/15/2013 10:19 AM, Jeff Davis wrote:
> On Thu, 2013-07-11 at 10:51 -0400, Nicholas White wrote:
>> I've attached a revised version that fixes the issues above:
>
> I'll get to this soon, sorry for the delay.
>
> Regards,
> Jeff Davis
So ... are you doing a final review of this for the
np, optimising for quality not speed :)
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Thu, 2013-07-11 at 10:51 -0400, Nicholas White wrote:
> I've attached a revised version that fixes the issues above:
I'll get to this soon, sorry for the delay.
Regards,
Jeff Davis
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscr
I've attached a revised version that fixes the issues above:
> changing a reference of the form:
> OVER w
> into:
> OVER (w)
Fixed (and I've updated the tests).
> It's bad form to modify a list while iterating through it.
Fixed
> We shouldn't create an arbitrary number of duplicate windows
On Mon, 2013-07-01 at 18:20 -0400, Nicholas White wrote:
> > pg_get_viewdef() needs to be updated
>
> Ah, good catch - I've fixed this in the attached. I also discovered
> that there's a parent-child hierarchy of WindowDefs (using
> relname->name), so instead of cloning the WindowDef (in parse_agg
30 matches
Mail list logo
