Andrew Dunstan <andrew@dunslane.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.
regards, tom lane
