Re: TODO items for window functions

2008/12/31 Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>:
> "Robert Haas" <robertmhaas(at)gmail(dot)com> writes:
>>> Apparently that analogy didn't impress anyone but me.
>
>> It impressed me. I liked making WINDOW a flag that occurs later in
>> the statement a lot better.
>
> I ended up going with the flag/attribute approach. The other would be
> only marginally more work now, but I remain convinced that we'd have to
> do more work later to deal with the issue that CREATE WINDOW FUNCTION
> looks like "window function" is a distinct kind of SQL object. And
> nobody seemed to want to propagate that distinction into all the places
> it would logically have to go.
>
> However ... having said that, there is more to David Fetter's gripe
> about \df than I realized at first. Consider
>
> regression=# \df nth_value
> List of functions
> Schema | Name | Result data type | Argument data types
> ------------+-----------+------------------+---------------------
> pg_catalog | nth_value | anyelement | anyelement, integer
> (1 row)
>
> Even without any consideration of user-defined window functions,
> this seems a bit lacking: the user of nth_value() needs to know that
> he has to write an OVER clause, and as things stand \df is not going
> to give him the slightest hint about that. So I can see the argument
> for reflecting window-ness into \df somehow.
>
> I am not thrilled about inventing a new column for this, but how about
> a display like so:
>
> regression=# \df nth_value
> List of functions
> Schema | Name | Result data type | Argument data types
> ------------+-----------+------------------+---------------------------------
> pg_catalog | nth_value | anyelement | anyelement, integer OVER window
>

+1

regards
Pavel Stehule

> or some other addition that only shows up when needed.
>
> regards, tom lane
>
> --
> Sent via pgsql-hackers mailing list (pgsql-hackers(at)postgresql(dot)org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-hackers
>