2008/12/31 Tom Lane <tgl@sss.pgh.pa.us>:
> "Robert Haas" <robertmhaas@gmail.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@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-hackers
>