I wrote:
> Attached is a proposed patch against HEAD that fixes this by supporting
> default arguments properly for window functions. In passing, it also
> allows named-argument notation in window function calls, since that's
> free once the other thing works (because the same subroutine fixes up
I wrote:
> I noticed this while poking at the variadic-aggregates issue:
> regression=# create function nth_value_def(anyelement, integer = 1) returns
> anyelement language internal window immutable strict as 'window_nth_value';
> CREATE FUNCTION
> regression=# SELECT nth_value_def(ten) OVER (PART
Robert Haas writes:
> On Fri, Aug 30, 2013 at 6:14 PM, Tom Lane wrote:
>> The reason this crashes is that the planner doesn't apply
>> default-insertion to WindowFunc nodes, only to FuncExprs.
> I'm not sure I agree. Under that approach, any functions that have
> already been created like that
On Fri, Aug 30, 2013 at 6:14 PM, Tom Lane wrote:
> I noticed this while poking at the variadic-aggregates issue:
>
> regression=# create function nth_value_def(anyelement, integer = 1) returns
> anyelement language internal window immutable strict as 'window_nth_value';
> CREATE FUNCTION
> regres
I noticed this while poking at the variadic-aggregates issue:
regression=# create function nth_value_def(anyelement, integer = 1) returns
anyelement language internal window immutable strict as 'window_nth_value';
CREATE FUNCTION
regression=# SELECT nth_value_def(ten) OVER (PARTITION BY four), te
Alvaro Herrera writes:
> CREATE TABLE foo AS SELECT a, a % 10 AS b FROM generate_series(1, 10) a;
> CREATE INDEX a_b ON foo (b);
> CREATE VIEW bar AS SELECT a, b, lead(a, 1) OVER () FROM foo;
> explain select a, b, lead(a, 1) over () from foo where b = 2;
> explain select * from bar where b =
Hi,
I've got a table and view defined like this:
CREATE TABLE foo AS SELECT a, a % 10 AS b FROM generate_series(1, 10) a;
CREATE INDEX a_b ON foo (b);
CREATE VIEW bar AS SELECT a, b, lead(a, 1) OVER () FROM foo;
Now, if I query the table directly instead of going through the view, a
WHERE co
2009/9/2 Tom Lane :
> Pavel Stehule writes:
>> create table x1 (a integer);
>> insert into x1
>> values(2),(2),(3),(3),(4),(4),(5),(5),(6),(6),(6),(8),(9),(9),(10),(10);
>
>> postgres=# select row_number() over (order by a), row_number() over
>> (order by a desc) from x1;
>> row_number | row_num
Pavel Stehule writes:
> create table x1 (a integer);
> insert into x1
> values(2),(2),(3),(3),(4),(4),(5),(5),(6),(6),(6),(8),(9),(9),(10),(10);
> postgres=# select row_number() over (order by a), row_number() over
> (order by a desc) from x1;
> row_number | row_number
> +--
Hello,
I wrote article about statistical function - when I tested Joe Celko's
method, I found some problems on not unique dataset:
on distinct dataset is rule so rows here is max(hi), then there is min(lo):
create table x1 (a integer);
insert into x1 select generate_series(1,10);
postgres=# se
2008/12/27 Tom Lane :
> "Robert Haas" writes:
>> Unfortunately, if we don't want to add an explicit iswindowable flag
>> (and I understand that that's ugly), then I think this is the way to
>> go. It's a shame that people will have to make code changes, but
>> inventing a fake AggState object jus
"Robert Haas" writes:
> Unfortunately, if we don't want to add an explicit iswindowable flag
> (and I understand that that's ugly), then I think this is the way to
> go. It's a shame that people will have to make code changes, but
> inventing a fake AggState object just to get around this problem
> 1. Go back to Hitoshi's plan of passing WindowAggState to the
> aggregates. This will require changing every one of the ten aggregates
> in the core distro, as well as every third-party aggregate that has
> a similar optimization; and we just have to keep our fingers crossed
> that anyone who's
On Fri, Dec 26, 2008 at 02:17:29PM -0500, Tom Lane wrote:
> So the alternatives I see are:
>
> 1. Go back to Hitoshi's plan of passing WindowAggState to the
> aggregates. This will require changing every one of the ten aggregates
> in the core distro, as well as every third-party aggregate that
"Joshua D. Drake" writes:
> I believe the goal should be correctness but why not both? Fix what we
> can and put in place a "work around" that would be removed in 8.5?
Why not both what? The driving concern here is that there might be
third-party aggregates that will dump core if invoked as wind
On Fri, 2008-12-26 at 14:17 -0500, Tom Lane wrote:
> Greg Stark writes:
> > Yeah, it seems like adding a flag like iswindowable to aggregate
> > functions is the safest option.
>
> So the alternatives I see are:
>
> 1. Go back to Hitoshi's plan of passing WindowAggState to the
> aggregates.
Greg Stark writes:
> Yeah, it seems like adding a flag like iswindowable to aggregate
> functions is the safest option.
I agree with Hitoshi-san: that's passing information in the wrong
direction. The right direction is to make it visible to the called
function which context it's being called
2008/12/25 Pavel Stehule :
> 2008/12/25 Hitoshi Harada :
>> 2008/12/25 Greg Stark :
>>> Yeah, it seems like adding a flag like iswindowable to aggregate functions
>>> is the safest option.
>>>
>>> It would be nice if it represented an abstract property of the state
>>> function or final function ra
2008/12/25 Hitoshi Harada :
> 2008/12/25 Greg Stark :
>> Yeah, it seems like adding a flag like iswindowable to aggregate functions
>> is the safest option.
>>
>> It would be nice if it represented an abstract property of the state
>> function or final function rather than just "works with the impl
2008/12/25 Greg Stark :
> Yeah, it seems like adding a flag like iswindowable to aggregate functions
> is the safest option.
>
> It would be nice if it represented an abstract property of the state
> function or final function rather than just "works with the implementation
> of window functions".
Yeah, it seems like adding a flag like iswindowable to aggregate
functions is the safest option.
It would be nice if it represented an abstract property of the state
function or final function rather than just "works with the
implementation of window functions". I'm not sure what that prope
2008/12/25 Tom Lane :
> Gregory Stark writes:
>> Tom Lane writes:
>>> Unless we want to move the goalposts on what an aggregate is allowed
>>> to do internally, we're going to have to change this to re-aggregate
>>> repeatedly. Neither prospect is appetizing in the least.
>
>> Does it currently
Gregory Stark writes:
> Tom Lane writes:
>> Unless we want to move the goalposts on what an aggregate is allowed
>> to do internally, we're going to have to change this to re-aggregate
>> repeatedly. Neither prospect is appetizing in the least.
> Does it currently copy the state datum before ca
Tom Lane writes:
> The window functions patch is laboring under the delusion that it can
> call an aggregate's final function and then go back to invoking the
> transfn some more on the same data. This is merest fantasy :-(
>
> regression=# select array_agg(q1) over(order by q1) from int8_tbl;
>
The window functions patch is laboring under the delusion that it can
call an aggregate's final function and then go back to invoking the
transfn some more on the same data. This is merest fantasy :-(
regression=# select array_agg(q1) over(order by q1) from int8_tbl;
server closed the connection
2008/11/22 Heikki Linnakangas <[EMAIL PROTECTED]>:
> Just to let you know, I'm hacking this patch again, the executor part in
> particular. I've got a stripped out the unfinished window frame stuff,
> refactored the Window object API so that the window functions don't get to,
> and don't need to, a
Just to let you know, I'm hacking this patch again, the executor part in
particular. I've got a stripped out the unfinished window frame stuff,
refactored the Window object API so that the window functions don't get
to, and don't need to, access tuple slots directly. And a bunch of other
simpli
Thank you for your reviewing my code.
2008/11/12 Heikki Linnakangas <[EMAIL PROTECTED]>:
> I've been slicing and dicing this patch for the last few days. There's a lot
> of code in there, but here's some initial comments:
>
> The code to initialize, advance, and finalize an aggregate should be sha
I've been slicing and dicing this patch for the last few days. There's a
lot of code in there, but here's some initial comments:
The code to initialize, advance, and finalize an aggregate should be
shared between Agg and Window nodes.
I'm a bit disappointed that we need so much code to suppor
2008/11/1 Tom Lane <[EMAIL PROTECTED]>:
> Gregory Stark <[EMAIL PROTECTED]> writes:
>> "Hitoshi Harada" <[EMAIL PROTECTED]> writes:
>>> 2008/11/1 David Fetter <[EMAIL PROTECTED]>:
>>> I've ever sent a patch over 100k and failed. Actually how much is the
>>> limitation of the patch size? And if the
Gregory Stark <[EMAIL PROTECTED]> writes:
> "Hitoshi Harada" <[EMAIL PROTECTED]> writes:
>> 2008/11/1 David Fetter <[EMAIL PROTECTED]>:
>> I've ever sent a patch over 100k and failed. Actually how much is the
>> limitation of the patch size? And if the patch is too huge, is it
>> better to split th
"Hitoshi Harada" <[EMAIL PROTECTED]> writes:
> 2008/11/1 David Fetter <[EMAIL PROTECTED]>:
>> On Fri, Oct 31, 2008 at 01:00:38PM -0300, Alvaro Herrera wrote:
>>> Hitoshi Harada escribió:
>>>
>>> > [Patch itself]
>>> > http://umitanuki.net/pgsql/wfv08/window_functions.patch.20081031.gz
>>>
>>> Plea
2008/11/1 David Fetter <[EMAIL PROTECTED]>:
> On Fri, Oct 31, 2008 at 01:00:38PM -0300, Alvaro Herrera wrote:
>> Hitoshi Harada escribió:
>>
>> > [Patch itself]
>> > http://umitanuki.net/pgsql/wfv08/window_functions.patch.20081031.gz
>>
>> Please send the patch to the pgsql-hackers list too. That
Hitoshi Harada escribió:
> [Patch itself]
> http://umitanuki.net/pgsql/wfv08/window_functions.patch.20081031.gz
Please send the patch to the pgsql-hackers list too. That way we will
have the patch around, even if the site above goes away in a few years.
--
Alvaro Herrera
I have completed my work on the patch for commit fest.
[Design Doc]
http://umitanuki.net/pgsql/wfv08/design.html
[Patch itself]
http://umitanuki.net/pgsql/wfv08/window_functions.patch.20081031.gz
[Git repository]
http://git.postgresql.org/git/~davidfetter/window_functions/.git
All compiler warn
2008/10/29 Tom Lane <[EMAIL PROTECTED]>:
> Martijn van Oosterhout <[EMAIL PROTECTED]> writes:
>> On Tue, Oct 28, 2008 at 01:50:26PM -0400, Tom Lane wrote:
>>> ... So it might be possible to fix
>>> by attaching some new precedence level to the ROWS token.
>
>> Yes. Bison's default is to shift, whic
Martijn van Oosterhout <[EMAIL PROTECTED]> writes:
> On Tue, Oct 28, 2008 at 01:50:26PM -0400, Tom Lane wrote:
>> ... So it might be possible to fix
>> by attaching some new precedence level to the ROWS token.
> Yes. Bison's default is to shift, which means that if you do nothing it
> will treat R
On Tue, Oct 28, 2008 at 01:50:26PM -0400, Tom Lane wrote:
> > Given that the only problematic case is if expr_list ends with a
> > postfix operator, wouldn't it be sufficient to simply decree that in
> > that case you need parentheses? Seems a lot less painful than adding
> > two reserved words.
>
Martijn van Oosterhout <[EMAIL PROTECTED]> writes:
> On Tue, Oct 28, 2008 at 12:38:09PM -0400, Tom Lane wrote:
>> Right offhand, I don't see any alternative but to make both ROWS and
>> RANGE reserved. It's pretty annoying since that might break existing
>> applications that have been using these
On Tue, Oct 28, 2008 at 12:38:09PM -0400, Tom Lane wrote:
> "Hitoshi Harada" <[EMAIL PROTECTED]> writes:
> > In window specifications, we have
>
> > OVER (ORDER BY expr_list [(ROWS|RANGE) ... ])
>
> > and currently "ROWS" is not reserved so bison is confused with cases
> > of "ROWS" included in e
2008/10/29 Tom Lane <[EMAIL PROTECTED]>:
> "Hitoshi Harada" <[EMAIL PROTECTED]> writes:
>> Can "ROWS" be reserved_keyword?
>
>> In window specifications, we have
>
>> OVER (ORDER BY expr_list [(ROWS|RANGE) ... ])
>
>> and currently "ROWS" is not reserved so bison is confused with cases
>> of "ROWS"
"Hitoshi Harada" <[EMAIL PROTECTED]> writes:
> Can "ROWS" be reserved_keyword?
> In window specifications, we have
> OVER (ORDER BY expr_list [(ROWS|RANGE) ... ])
> and currently "ROWS" is not reserved so bison is confused with cases
> of "ROWS" included in expr_list and in FRAME clause. Because
2008/10/28 Tom Lane <[EMAIL PROTECTED]>:
> "Hitoshi Harada" <[EMAIL PROTECTED]> writes:
>> OK, I'll try to remove it. I'm not used to bison so my first task is
>> to find where the conflict is...
>
> Use bison -v to get details of where the conflict is. I find that
> the most common way to fix thi
"Hitoshi Harada" <[EMAIL PROTECTED]> writes:
> OK, I'll try to remove it. I'm not used to bison so my first task is
> to find where the conflict is...
Use bison -v to get details of where the conflict is. I find that
the most common way to fix things is to postpone where the parser
has to make a
2008/10/28 Tom Lane <[EMAIL PROTECTED]>:
> "Hitoshi Harada" <[EMAIL PROTECTED]> writes:
>> 2008/10/28 ITAGAKI Takahiro <[EMAIL PROTECTED]>:
>>> I tested the patch on mingw (Windows) and
>>> got the following warning and error:
>>>
>>> A. gram.y: conflicts: 3 shift/reduce
>>> B. include/nodes/planno
"Hitoshi Harada" <[EMAIL PROTECTED]> writes:
> 2008/10/28 ITAGAKI Takahiro <[EMAIL PROTECTED]>:
>> I tested the patch on mingw (Windows) and
>> got the following warning and error:
>>
>> A. gram.y: conflicts: 3 shift/reduce
>> B. include/nodes/plannodes.h:650: error: syntax error before "uint"
>>
2008/10/28 ITAGAKI Takahiro <[EMAIL PROTECTED]>:
>
> "Hitoshi Harada" <[EMAIL PROTECTED]> wrote:
>
>> And I fixed this problem, confirming with/without debug/cassert/gcc
>> -O and push it to git. If you want delta patch, please see
>> http://git.postgresql.org/?p=~davidfetter/window_functions/.git
"Hitoshi Harada" <[EMAIL PROTECTED]> wrote:
> And I fixed this problem, confirming with/without debug/cassert/gcc
> -O and push it to git. If you want delta patch, please see
> http://git.postgresql.org/?p=~davidfetter/window_functions/.git;a=commitdiff;h=fbf19bfd0c8d2ac083b775f4cc724ec66e74fa8f
2008/10/28 Hitoshi Harada <[EMAIL PROTECTED]>:
> Thanks for your testing all!
>
> 2008/10/28 ITAGAKI Takahiro <[EMAIL PROTECTED]>:
>> "Hitoshi Harada" <[EMAIL PROTECTED]> wrote:
>>
>>
>>> select relid,AVG(seq_Scan) OVER (ORDER BY relid)
>>> FROM pg_stat_user_tables
>>> GROUP BY relid,seq_scan;
>>
>
Thanks for your testing all!
2008/10/28 ITAGAKI Takahiro <[EMAIL PROTECTED]>:
> "Hitoshi Harada" <[EMAIL PROTECTED]> wrote:
>
>> As I promised, version 7 of the window functions is now released.
>> patch: http://umitanuki.net/pgsql/window_functions.patch.20081028.gz
>
> I tested the patch on mingw
"Hitoshi Harada" <[EMAIL PROTECTED]> wrote:
> As I promised, version 7 of the window functions is now released.
> patch: http://umitanuki.net/pgsql/window_functions.patch.20081028.gz
I tested the patch on mingw (Windows) and
got the following warning and error:
A. gram.y: conflicts: 3 shift/re
2008/10/28 David Rowley <[EMAIL PROTECTED]>:
> Hitoshi Harada Wrote:
>
>> As I promised, version 7 of the window functions is now released. At
>> the same time, git repository branch comes back to master.
>>
>> git: http://git.postgresql.org/?p=~davidfetter/window_functions/.git
>> patch: http://um
Hitoshi Harada Wrote:
> As I promised, version 7 of the window functions is now released. At
> the same time, git repository branch comes back to master.
>
> git: http://git.postgresql.org/?p=~davidfetter/window_functions/.git
> patch: http://umitanuki.net/pgsql/window_functions.patch.20081028.gz
As I promised, version 7 of the window functions is now released. At
the same time, git repository branch comes back to master.
git: http://git.postgresql.org/?p=~davidfetter/window_functions/.git
patch: http://umitanuki.net/pgsql/window_functions.patch.20081028.gz
It's too huge to send it to thi
2008/10/21 Heikki Linnakangas <[EMAIL PROTECTED]>:
> Hitoshi Harada wrote:
>>
>> The real problem is not how to cut off preceding rows, but how to read
>> ahead after the current row. I intend to avoid reading ahead until end
>> of the partition for only row_number() that doesn't need any following
Hitoshi Harada wrote:
The real problem is not how to cut off preceding rows, but how to read
ahead after the current row. I intend to avoid reading ahead until end
of the partition for only row_number() that doesn't need any following
rows. Sometimes we have to store whole the partition before re
2008/10/20 Heikki Linnakangas <[EMAIL PROTECTED]>:
> Hitoshi Harada wrote:
>>
>> Hi,
>>
>> 2008/10/20 Simon Riggs <[EMAIL PROTECTED]>:
>>>
>>> On Mon, 2008-10-20 at 10:32 +0900, Hitoshi Harada wrote:
>>>
So I propose three Window node buffering strategies,
row/frame/partition buffering so
Hitoshi Harada wrote:
Hi,
2008/10/20 Simon Riggs <[EMAIL PROTECTED]>:
On Mon, 2008-10-20 at 10:32 +0900, Hitoshi Harada wrote:
So I propose three Window node buffering strategies,
row/frame/partition buffering so as to avoid unnecessary row
buffering.
Sounds good from here. Can I suggest you
Hi,
2008/10/20 Simon Riggs <[EMAIL PROTECTED]>:
>
> On Mon, 2008-10-20 at 10:32 +0900, Hitoshi Harada wrote:
>
>> So I propose three Window node buffering strategies,
>> row/frame/partition buffering so as to avoid unnecessary row
>> buffering.
>
> Sounds good from here. Can I suggest you release
On Mon, 2008-10-20 at 10:32 +0900, Hitoshi Harada wrote:
> So I propose three Window node buffering strategies,
> row/frame/partition buffering so as to avoid unnecessary row
> buffering.
Sounds good from here. Can I suggest you release the code in phases?
It would be better if we got just one
> I can find how to do it with the new (window execution model) design,
> (and the design is suitable to fix it above,) but at first before
> going into trivial specs, I would like core hackers to review the
> model is better than before or not. Thank you for your cooperation.
So no objections app
2008/10/15 Andreas Joseph Krogh <[EMAIL PROTECTED]>:
> On Tuesday 14 October 2008 18:19:07 Hannu Krosing wrote:
>> On Tue, 2008-10-14 at 11:05 +0200, Andreas Joseph Krogh wrote:
>> > Hi all.
>> > This is not very "hackers"-related, but related to the topic of
>> > window-funcitons, which seems to
On Tue, 2008-10-14 at 19:04 +0200, Andreas Joseph Krogh wrote:
> On Tuesday 14 October 2008 18:19:07 Hannu Krosing wrote:
> > On Tue, 2008-10-14 at 11:05 +0200, Andreas Joseph Krogh wrote:
> > > Hi all.
> > > This is not very "hackers"-related, but related to the topic of
> > > window-funcitons, w
On Tuesday 14 October 2008 18:19:07 Hannu Krosing wrote:
> On Tue, 2008-10-14 at 11:05 +0200, Andreas Joseph Krogh wrote:
> > Hi all.
> > This is not very "hackers"-related, but related to the topic of
> > window-funcitons, which seems to be discussed quite a bit on "hackers"
> > these days.
> >
On Tue, 2008-10-14 at 11:05 +0200, Andreas Joseph Krogh wrote:
> Hi all.
> This is not very "hackers"-related, but related to the topic of
> window-funcitons, which seems to be discussed quite a bit on "hackers" these
> days.
>
> Can window-functions in PG be used to return "total number of rows
Hi all.
This is not very "hackers"-related, but related to the topic of
window-funcitons, which seems to be discussed quite a bit on "hackers" these
days.
Can window-functions in PG be used to return "total number of rows" in a "paged
result"?
Say you have:
SELECT p.id, p.firstname
FROM perso
"Hitoshi Harada" <[EMAIL PROTECTED]> writes:
> I agree I need to work on that. Also from the spec, "RESPECT NULLS /
> IGNORE NULLS" may be specified but not supported yet. This syntax
> specification is out of the postgres general function call so I wonder
> if those functions are treated specially
2008/10/14 David Rowley <[EMAIL PROTECTED]>:
> Hitoshi Harada wrote:
>>I made up my mind to scratch former window functions and redesigned
>>completely new execution model, based on the discussion with Heikki.
>>Attached is the v06 against HEAD today.
>>http://umitanuki.net/pgsql/wfv06/design.html
Hitoshi Harada wrote:
>I made up my mind to scratch former window functions and redesigned
>completely new execution model, based on the discussion with Heikki.
>Attached is the v06 against HEAD today.
>http://umitanuki.net/pgsql/wfv06/design.html
First off, fantastic work!
In my eyes this and WI
I confirmed this on Oracle:
select last_value(id) over (order by id) as last_id, id from foo;
LAST_ID ID
--- --
0 0
1 1
2 2
3 3
4 4
5 5
6 6
7 7
8 8
9 9
10 10
So when you specify ORDER BY clause on window definition, the frame
a
2008/10/11 Hitoshi Harada <[EMAIL PROTECTED]>:
> I am drunk. I forgot cc to -hackers. The talk between me and Ian was like
> that.
>
> 2008/10/12 Hitoshi Harada <[EMAIL PROTECTED]>:
>> 2008/10/12 Ian Caulfield <[EMAIL PROTECTED]>:
>>> 2008/10/11 Hitoshi Harada <[EMAIL PROTECTED]>:
2008/10/12
I am drunk. I forgot cc to -hackers. The talk between me and Ian was like that.
2008/10/12 Hitoshi Harada <[EMAIL PROTECTED]>:
> 2008/10/12 Ian Caulfield <[EMAIL PROTECTED]>:
>> 2008/10/11 Hitoshi Harada <[EMAIL PROTECTED]>:
>>> 2008/10/12 Ian Caulfield <[EMAIL PROTECTED]>:
2008/10/11 Hitoshi
2008/10/11 Hitoshi Harada <[EMAIL PROTECTED]>
>
> I'm afraid the patch was too huge, trying to send it again without
> attachment...
>
> I made up my mind to scratch former window functions and redesigned
> completely new execution model, based on the discussion with Heikki.
> Attached is the v06
I'm afraid the patch was too huge, trying to send it again without attachment...
I made up my mind to scratch former window functions and redesigned
completely new execution model, based on the discussion with Heikki.
Attached is the v06 against HEAD today.
http://umitanuki.net/pgsql/wfv06/design
>> Also, current implementation has only a type of plan which uses sort
>> operation. It should be optimized by re-position the windows and/or
>> using hashtable.
>
> I would like to see some performance test results also. It would be good
> to know whether they are fast/slow etc.. It will definite
2008/9/5 Heikki Linnakangas <[EMAIL PROTECTED]>:
> Heikki Linnakangas wrote:
>>
>> I'll review the parser/planner changes from the current patch.
>
> Looks pretty sane to me. Few issues:
>
> Is it always OK to share a window between two separate window function
> invocations, if they both happen to
Heikki Linnakangas wrote:
I'll review the parser/planner changes from the current patch.
Looks pretty sane to me. Few issues:
Is it always OK to share a window between two separate window function
invocations, if they both happen to have identical OVER clause? It seems
OK for stable function
Hitoshi Harada wrote:
BTW, I think it is better to put together the discussion points we
have done as "general roadmap to complete window functions". It is not
about the features for the next release but is the complete tasks.
Where to go? Wiki, or my design docs?
That's up to you, really. I li
2008/9/4 Erikj <[EMAIL PROTECTED]>:
> Dear Hitoshi,
>
> I noticed the folowing typo in the doc sgml:
>
> 'rownumber()', instead of 'row_number()' ( 2x )
>
> hth
>
> Erik Rijkers
>
>
>
> *** doc/src/sgml/func.sgml.orig 2008-09-03 17:20:28.130229027 +0200
> --- doc/src/sgml/func.sgml 2008-09-03
Dear Hitoshi,
I noticed the folowing typo in the doc sgml:
'rownumber()', instead of 'row_number()' ( 2x )
hth
Erik Rijkers
*** doc/src/sgml/func.sgml.orig 2008-09-03 17:20:28.130229027 +0200
--- doc/src/sgml/func.sgml 2008-09-03 17:21:01.331907454 +0200
***
*** 10092,1010
2008/9/3 Heikki Linnakangas <[EMAIL PROTECTED]>:
> Hitoshi Harada wrote:
>>
>>> I'd suggest:
>>>
>>> 1. Implement Window node, with the capability to invoke an aggregate
>>> function, using the above API. Implement required parser/planner changes.
>>> Implement a few simple ranking aggregates using
On Wed, 2008-09-03 at 09:51 +0300, Heikki Linnakangas wrote:
> Simon Riggs wrote:
> > On Tue, 2008-09-02 at 15:51 +0300, Heikki Linnakangas wrote:
> >
> >> The needs of access to the rows are so different that it seems best to
> >> me to delegate the buffering to the window function.
> >
> > Tha
Hitoshi Harada wrote:
2008/9/2 Heikki Linnakangas <[EMAIL PROTECTED]>:
Hitoshi Harada wrote:
2008/9/2 Heikki Linnakangas <[EMAIL PROTECTED]>:
In my understanding, the "Window Frame" is defined
by clauses such like "ROWS BETWEEN ... ", "RANGE BETWEEN ... " or so,
contrast to "Window Partition" d
Simon Riggs wrote:
On Tue, 2008-09-02 at 15:51 +0300, Heikki Linnakangas wrote:
The needs of access to the rows are so different that it seems best to
me to delegate the buffering to the window function.
That seems sensible in some ways, not others.
In the API I proposed later in that mail,
On Tue, 2008-09-02 at 15:51 +0300, Heikki Linnakangas wrote:
> The needs of access to the rows are so different that it seems best to
> me to delegate the buffering to the window function.
That seems sensible in some ways, not others.
Some of the window functions, like lead and lag merely speci
2008/9/2 Heikki Linnakangas <[EMAIL PROTECTED]>:
> Hitoshi Harada wrote:
>>
>> 2008/9/2 Heikki Linnakangas <[EMAIL PROTECTED]>:
>> In my understanding, the "Window Frame" is defined
>> by clauses such like "ROWS BETWEEN ... ", "RANGE BETWEEN ... " or so,
>> contrast to "Window Partition" defined by
On Tue, Sep 2, 2008 at 9:35 AM, David Fetter <[EMAIL PROTECTED]> wrote:
> Any chance we can buy a few copies of the official one for use on the
> project?
AFAIK there is no significant difference between the "official"
standard and the draft version available online, so I don't see the
point.
Nei
On Tue, 2008-09-02 at 09:35 -0700, David Fetter wrote:
> On Tue, Sep 02, 2008 at 12:42:45PM +0100, Simon Riggs wrote:
> >
> > On Tue, 2008-09-02 at 03:14 -0400, Tom Lane wrote:
> > > David Fetter <[EMAIL PROTECTED]> writes:
> > > > On Tue, Sep 02, 2008 at 02:42:25AM -0400, Tom Lane wrote:
> > > >
On Tue, Sep 02, 2008 at 12:42:45PM +0100, Simon Riggs wrote:
>
> On Tue, 2008-09-02 at 03:14 -0400, Tom Lane wrote:
> > David Fetter <[EMAIL PROTECTED]> writes:
> > > On Tue, Sep 02, 2008 at 02:42:25AM -0400, Tom Lane wrote:
> > >> It's not like we haven't seen a SQL draft go down in flames
> > >>
Martijn van Oosterhout wrote:
On Tue, Sep 02, 2008 at 10:44:31AM +0100, Simon Riggs wrote:
If we only have the combined (brain * time) to get a partial
implementation in for this release then I would urge we go for that,
rather than wait for perfection - as long as there are no other negative
ef
Hitoshi Harada wrote:
2008/9/2 Heikki Linnakangas <[EMAIL PROTECTED]>:
In my understanding, the "Window Frame" is defined
by clauses such like "ROWS BETWEEN ... ", "RANGE BETWEEN ... " or so,
contrast to "Window Partition" defined by "PARTITION BY" clause. A
frame slides within a partition or the
2008/9/2 Simon Riggs <[EMAIL PROTECTED]>:
> If you've done all of that, then I'm impressed. Well done.
>
> Few general comments
>
> * The docs talk about "windowing functions", yet you talk about "window
> functions" here. I think the latter is correct, but whichever we choose
> we should be consis
On Tue, 2008-09-02 at 03:14 -0400, Tom Lane wrote:
> David Fetter <[EMAIL PROTECTED]> writes:
> > On Tue, Sep 02, 2008 at 02:42:25AM -0400, Tom Lane wrote:
> >> It's not like we haven't seen a SQL draft go down in flames before.
>
> > Do you think that anything in the windowing functions section
On Tue, Sep 02, 2008 at 10:44:31AM +0100, Simon Riggs wrote:
> If we only have the combined (brain * time) to get a partial
> implementation in for this release then I would urge we go for that,
> rather than wait for perfection - as long as there are no other negative
> effects.
"premature optimi
On Mon, 2008-09-01 at 21:00 +0300, Heikki Linnakangas wrote:
> 1. It's important that what gets committed now can be extended to handle
> all of the window function stuff in SQL2003 in the future, as well as
> user-defined-window-functions in the spirit of PostgreSQL extensibility.
> Even if w
On Sat, 2008-08-30 at 02:04 +0900, Hitoshi Harada wrote:
> Here's the latest window functions patch against HEAD. It seems to be
> ready for the September commit fest, as added documents, WINDOW clause
> feature and misc tests. I guess this would be the window functions
> feature freeze for 8.4.
2008/9/2 Heikki Linnakangas <[EMAIL PROTECTED]>:
> Gregory Stark wrote:
>> What would the executor do for a query like
>>
>> SELECT lead(x,1),lead(y,2),lead(y,3)
>>
>> It would not only have to keep a tuplestore to buffer the output but it
>> would
>> have to deal with receiving data from different
Tom Lane wrote:
David Fetter <[EMAIL PROTECTED]> writes:
On Tue, Sep 02, 2008 at 02:42:25AM -0400, Tom Lane wrote:
It's not like we haven't seen a SQL draft go down in flames before.
Do you think that anything in the windowing functions section will
disappear?
Who's to say?
I have no obje
David Fetter <[EMAIL PROTECTED]> writes:
> On Tue, Sep 02, 2008 at 02:42:25AM -0400, Tom Lane wrote:
>> It's not like we haven't seen a SQL draft go down in flames before.
> Do you think that anything in the windowing functions section will
> disappear?
Who's to say?
I have no objection to looki
On Tue, Sep 02, 2008 at 02:42:25AM -0400, Tom Lane wrote:
> Heikki Linnakangas <[EMAIL PROTECTED]> writes:
> > David Fetter wrote:
> >> On Mon, Sep 01, 2008 at 09:00:47PM +0300, Heikki Linnakangas wrote:
> >>> Ok, I'm starting to read up on SQL2003 window functions,
> >>
> >> Maybe it would be bet
1 - 100 of 111 matches
Mail list logo
