Peter Eisentraut writes:
> On 2/4/18 13:10, Tom Lane wrote:
>> + 22013EERRCODE_INVALID_PRECEDING_FOLLOWING_SIZE
>> invalid_preceding_following_size
> I was checking the new error codes in PostgreSQL 11 and came across
> this. The original name in the SQL standard i
On 2/4/18 13:10, Tom Lane wrote:
> diff --git a/src/backend/utils/errcodes.txt b/src/backend/utils/errcodes.txt
> index 1475bfe..9871d1e 100644
> *** a/src/backend/utils/errcodes.txt
> --- b/src/backend/utils/errcodes.txt
> *** Section: Class 22 - Data Exception
> *** 177,182
> ---
On Sun, Feb 4, 2018 at 6:10 PM, Tom Lane wrote:
> Oliver Ford writes:
> > [ 0001-window-frame-v13.patch ]
>
> I've been hacking on this all week (with breaks for release notes) and
> have gotten it into a state that I think is close to committable.
>
> There was quite a lot I didn't like about t
I wrote:
> [ 0001-window-frame-v14.patch ]
Pushed after further hacking on the documentation and test cases.
I went ahead with the "value" to "offset" terminology change, too.
You mentioned upthread that you were interested in adding more in_range
support functions. I think it'd be a great idea
On Fri, Feb 2, 2018 at 9:26 AM, Oliver Ford wrote:
> On Thu, Feb 1, 2018 at 1:46 AM, David G. Johnston
> wrote:
>
> > The three callers of WinGetFuncArgInFrame don't use the isout argument;
> they
> > probably need to read that and a new isexcluded argument. Start at the
> > head, loop until is
On Wed, Jan 31, 2018 at 5:06 PM, Tom Lane wrote:
> We could imagine reimplementing WinGetFuncArgInFrame to fix this, but
> aside from the sheer inefficiency of simple fixes, I'm not very clear
> what seeking relative to WINDOW_SEEK_CURRENT should mean when the current
> row is excluded. (Of cour
Oliver Ford writes:
> [ 0001-window-frame-v11.patch ]
I've realized that the exclusion clause aspect of this patch is rather
badly broken. In particular, the "seek to row" logic in
WinGetFuncArgInFrame is critically dependent on the assumption that the
rows of the frame are contiguous. Use of a
Once more trying to attach the regression.diffs
On 2018-01-30 17:31, Erik Rijkers wrote:
On 2018-01-30 17:08, Oliver Ford wrote:
On Tue, Jan 30, 2018 at 10:48 AM, Oliver Ford
wrote:
I will send out v10 soon with the desc functions removed and the
EXCLUDE_NO_OTHERS define removed.
Here it
On 2018-01-30 17:08, Oliver Ford wrote:
On Tue, Jan 30, 2018 at 10:48 AM, Oliver Ford wrote:
I will send out v10 soon with the desc functions removed and the
EXCLUDE_NO_OTHERS define removed.
Here it is. Exclude No Others is still in the parser, but does
nothing. All desc functions are remov
On Tuesday, 30 January 2018, Tom Lane wrote:
> Another thing I'm a little confused by is the precise API for the in_range
> support functions (the lack of any documentation for it doesn't help).
> I wonder why you chose to provide two support functions per datatype
> combination rather than one w
Another thing I'm a little confused by is the precise API for the in_range
support functions (the lack of any documentation for it doesn't help).
I wonder why you chose to provide two support functions per datatype
combination rather than one with an additional boolean argument.
In fact, it almost
On Monday, 29 January 2018, Tom Lane wrote:
> Oliver Ford writes:
> > On Monday, 29 January 2018, Tom Lane wrote:
> >> I've started to go through this in some detail, and I'm wondering why
> >> you invented a FRAMEOPTION_EXCLUDE_NO_OTHERS option bit rather than
> >> just representing that choic
Oliver Ford writes:
> On Monday, 29 January 2018, Tom Lane wrote:
>> I've started to go through this in some detail, and I'm wondering why
>> you invented a FRAMEOPTION_EXCLUDE_NO_OTHERS option bit rather than
>> just representing that choice as default (0).
> My guess is that it's a little like
On Monday, 29 January 2018, Tom Lane wrote:
> Oliver Ford writes:
> > [ 0001-window-frame-v9.patch ]
>
> I've started to go through this in some detail, and I'm wondering why
> you invented a FRAMEOPTION_EXCLUDE_NO_OTHERS option bit rather than
> just representing that choice as default (0). As
Oliver Ford writes:
> [ 0001-window-frame-v9.patch ]
I've started to go through this in some detail, and I'm wondering why
you invented a FRAMEOPTION_EXCLUDE_NO_OTHERS option bit rather than
just representing that choice as default (0). As you have it, a
window definition that explicitly specifi
Oliver Ford writes:
> On Sat, Jan 27, 2018 at 7:40 AM, Erik Rijkers wrote:
>> Regression tests only succeed for assert-disabled compiles; they fail when
>> assert-enabled:
> Problem seems to be with an existing Assert in catcache.c:1545:
> Assert(nkeys > 0 && nkeys < cache->cc_nkeys);
> The "<"
On 2018-01-27 11:49, Oliver Ford wrote:
On Sat, Jan 27, 2018 at 7:40 AM, Erik Rijkers wrote:
On 2018-01-27 00:35, Oliver Ford wrote:
Attached patch implements an extensible version of the RANGE with
values clause. It doesn't actually add any more type support than was
[...]
I've tested th
Oliver Ford writes:
> On Tuesday, 9 January 2018, Tom Lane wrote:
>> So the approach I'm imagining now is a datatype-specific support function
>> along the lines of
>> in_range(a, b, delta) returns bool
>> Likely there are two of these, one each for the PRECEDING and FOLLOWING
>> cases.
> W
On Tuesday, 9 January 2018, Tom Lane wrote:
>
> So the approach I'm imagining now is a datatype-specific support function
> along the lines of
>
> in_range(a, b, delta) returns bool
>
> which is supposed to return true if a <= b + delta, or something along
> that line --- exact details of
Vik Fearing writes:
> I'm -1 on such a patch, even though I would really like this feature.
For the record, I'd really like to get this feature in too (and am
willing to help) ... but it needs to be done right.
regards, tom lane
On 01/09/2018 10:59 PM, Tom Lane wrote:
> Generally speaking, Postgres tries hard to be an extensible-datatype
> system, going beyond the SQL standard's minimum requirements when
> necessary to make it so. The reason that we don't already have RANGE
> PRECEDING/FOLLOWING support is that nobody was
Oliver Ford writes:
> [ 0001-window-frame-v6.patch ]
Generally speaking, Postgres tries hard to be an extensible-datatype
system, going beyond the SQL standard's minimum requirements when
necessary to make it so. The reason that we don't already have RANGE
PRECEDING/FOLLOWING support is that nob
On 2017-11-27 17:55, Oliver Ford wrote:
Cheers here's v4 with the correct docs.
This email just to link related thread "Add GROUPS option to the Window
Functions":
https://www.postgresql.org/message-id/CAGMVOdtWkb9X7dUh7vjaCaiH34UGFg88unXYTEOub0Rk0swSXw%40mail.gmail.com
On Tue, Nov 28, 2017 at 10:51:19AM +, Oliver Ford wrote:
> On Tue, Nov 28, 2017 at 4:38 AM, David Fetter wrote:
> > I've taken the liberty of adding float8, somewhat mechanically. Do
> > the docs need some change, assuming that addition is useful?
> >
> > Best,
> > David.
> > --
> > David Fet
On Tue, Nov 28, 2017 at 4:38 AM, David Fetter wrote:
> On Mon, Nov 27, 2017 at 04:55:17PM +, Oliver Ford wrote:
>> On Mon, Nov 27, 2017 at 4:40 PM, Erik Rijkers wrote:
>> > On 2017-11-27 17:34, Erik Rijkers wrote:
>> >>
>> >> On 2017-11-27 16:01, Oliver Ford wrote:
>> >>>
>> >>> Attached is i
On Mon, Nov 27, 2017 at 04:55:17PM +, Oliver Ford wrote:
> On Mon, Nov 27, 2017 at 4:40 PM, Erik Rijkers wrote:
> > On 2017-11-27 17:34, Erik Rijkers wrote:
> >>
> >> On 2017-11-27 16:01, Oliver Ford wrote:
> >>>
> >>> Attached is it in bare diff form.
> >>
> >>
> >> [0001-window-frame-v3.patc
On Mon, Nov 27, 2017 at 4:40 PM, Erik Rijkers wrote:
> On 2017-11-27 17:34, Erik Rijkers wrote:
>>
>> On 2017-11-27 16:01, Oliver Ford wrote:
>>>
>>> Attached is it in bare diff form.
>>
>>
>> [0001-window-frame-v3.patch]
>>
>> Thanks, that did indeed fix it:
>>
>> make && make check now ok.
>>
On 2017-11-27 17:34, Erik Rijkers wrote:
On 2017-11-27 16:01, Oliver Ford wrote:
Attached is it in bare diff form.
[0001-window-frame-v3.patch]
Thanks, that did indeed fix it:
make && make check now ok.
There were errors in the doc build (unmatched tags); I fixed them in
the attached doc-
On 2017-11-27 16:01, Oliver Ford wrote:
Attached is it in bare diff form.
[0001-window-frame-v3.patch]
Thanks, that did indeed fix it:
make && make check now ok.
There were errors in the doc build (unmatched tags); I fixed them in the
attached doc-patch (which should go on top of yours).
On Mon, Nov 27, 2017 at 12:06 PM, Oliver Ford wrote:
> On Fri, Nov 24, 2017 at 3:08 PM, Erikjan Rijkers wrote:
>> SELECT pg_get_viewdef('v_window');
>> ! pg_get_viewdef
>> ! --
>> ! SELECT i.i,+
>> !
On Fri, Nov 24, 2017 at 3:08 PM, Erikjan Rijkers wrote:
> SELECT pg_get_viewdef('v_window');
> ! pg_get_viewdef
> ! --
> ! SELECT i.i,+
> ! sum(i.i) OVER (ORDER BY i.i) AS sum_rows+
> FROM ge
On 24 November 2017 at 22:11, Oliver Ford wrote:
> Adds RANGE BETWEEN with a start and end value, as well as an
> exclusions clause, to the window functions. This partially resolves
> TODO list item "Implement full support for window framing clauses".
>
Yay!
I'll try to take a look at this.
--
On Fri, Nov 24, 2017 at 3:08 PM, Erikjan Rijkers wrote:
> (debian 8)
>
> make check fails:
>
> foreign_data ... ok
> window ... FAILED
> xmlmap ... ok
>
> The diff is:
>
> $ ( cd /var/data1/pg_stuff/pg_sandbox/pgsql.frame_range/src/te
On 2017-11-24 15:11, Oliver Ford wrote:
Adds RANGE BETWEEN with a start and end value, as well as an
exclusions clause, to the window functions. This partially resolves
TODO list item "Implement full support for window framing clauses".
[0001-window-frame-v1.patch]
(debian 8)
make check fails
Adds RANGE BETWEEN with a start and end value, as well as an
exclusions clause, to the window functions. This partially resolves
TODO list item "Implement full support for window framing clauses".
== Specification ==
The window functions already allow a "ROWS BETWEEN start_value
PRECEDING/FOLLOWI
35 matches
Mail list logo