Skip site navigation (1) Skip section navigation (2)

Re: TODO items for window functions

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: "Hitoshi Harada" <umi(dot)tanuki(at)gmail(dot)com>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: TODO items for window functions
Date: 2008-12-29 16:44:30
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
"Hitoshi Harada" <umi(dot)tanuki(at)gmail(dot)com> writes:
> 2008/12/29 Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>:
>> * Support creation of user-defined window functions.  I think this is
>> a "must have" for 8.4 --- we are not in the habit of building
>> nonextensible basic features.  It doesn't seem that hard either.

> The reason I and people decided window functions are not able to be
> defined by user is whether Window functions API is ready for exposure.

Well, it seems about as stable as any other bit of new backend code ;-).
We never promise that backend-internal APIs will not change across

> My only concern is for plpgsql. For c functions we can define user
> functions but what about other pls?

I'm not concerned about making this stuff available at the PL level
(at least not yet).  C-level capability will be enough to satisfy
my concern for 8.4.

> And surveying sgml docs, I found this is not correct.


> +     default framing behavior, which is equivalent to the framing clause

> the default frame with ORDER BY clause is RANGE BETWEEN UNBOUNDED
> PRECEDING AND CURRENT ROW, as aggregates perform rows peer to the
> current row.

What is the difference?  AFAICS the RANGE and ROWS keywords ought to be
equivalent if you are not specifying "expression PRECEDING" or
"expression FOLLOWING".

			regards, tom lane

In response to


pgsql-hackers by date

Next:From: Tom LaneDate: 2008-12-29 16:47:58
Subject: Re: About CMake (was Re: [COMMITTERS] pgsql: Append major version number and for libraries soname major)
Previous:From: Tom LaneDate: 2008-12-29 16:39:16
Subject: Re: ecpg regression test failures caused by window functions patch

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group