"Robert Haas" <robertmh...@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
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
