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

Re: TODO items for window functions

From: "Hitoshi Harada" <umi(dot)tanuki(at)gmail(dot)com>
To: "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: "Andrew Dunstan" <andrew(at)dunslane(dot)net>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: TODO items for window functions
Date: 2008-12-29 18:12:50
Message-ID: e08cc0400812291012s17e46b7bn62e598679727fb0e@mail.gmail.com (view raw or flat)
Thread:
Lists: pgsql-hackers
2008/12/30 Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>:
> Andrew Dunstan <andrew(at)dunslane(dot)net> writes:
>> Tom Lane wrote:
>>> However, if we do that then for consistency we'd have to invent
>>> DROP WINDOW FUNCTION, ALTER WINDOW FUNCTION, RENAME WINDOW FUNCTION,
>>> COMMENT ON WINDOW FUNCTION, yadda yadda, and insist that you refer
>>> to a function properly (with or without WINDOW) in each one of these
>>> commands.
>
>> I don't know that this matters so much unless you're going to have a
>> seperate namespace for window functions. Otherwise, isn't WINDOW
>> basically a noise word for these operations?
>
> Well, the question is whether window functions are so different from
> plain functions that we should treat them as a different kind of animal
> for SQL-command purposes.  We do do that for aggregate functions, but
> aggregates have some really fundamental effects on query semantics.
> Consider
>
> select sin(x) from table;               -- returns 1 row per table row
> select sum(x) from table;               -- returns 1 row
> select lead(x) over () from table;      -- returns 1 row per table row
>
> In this sense window functions aren't that different from regular ones.
>
> Window functions are also much more like regular functions than
> aggregates in terms of what you have to specify to define one.
>
> You could certainly argue the classification either way, but I think
> that we should make a hard decision now: either window functions are
> treated as a distinct object type (implying their own set of command
> names and nuisance errors if you use the wrong one), or they are not a
> distinct object type (implying that WINDOW is an attribute for CREATE
> FUNCTION and not part of the command name).  If we are wishy-washy about
> it and treat WINDOW as just a noise word in some contexts then we will
> have user confusion.  The precedent that is bothering me here is all the
> user confusion that has ensued over whether you can use ALTER TABLE to
> operate on sequences and views.

Hmm, sequences and views are created by
CREATE SEQUENCE
CREATE VIEW
but
CREATE WINDOW FUNCTION
is not so. I mean, by this syntax user recognizes he creates one of
the plain function with window attribute. And as I said in the
previous mail, actually it is. The proiswindow attribute is used to
declare that it can handle window function API and nothing more,
everything is the same with plain ones.


Regards,


-- 
Hitoshi Harada

In response to

pgsql-hackers by date

Next:From: Tom LaneDate: 2008-12-29 18:19:32
Subject: Re: TODO items for window functions
Previous:From: Tom LaneDate: 2008-12-29 18:03:12
Subject: Re: TODO items for window functions

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