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
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.
>
>
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
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
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
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
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
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
>
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
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).
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
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
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 &&
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
[...]
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
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
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
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
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.
>
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
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
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
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 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
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
29 matches
Mail list logo