Robert Haas wrote:
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
2009/2/5 Bruce Momjian br...@momjian.us:
Robert Haas wrote:
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
Robert Haas wrote:
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
Hi,
Happy new year!
Le 31 déc. 08 à 17:04, Tom Lane t...@sss.pgh.pa.us a écrit :
However, it seems kind of inconsistent to do this for window functions
unless we also make \df start putting parens around the argument lists
for regular functions. Comments?
A way to distinguish between window
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
2008/12/31 Tom Lane t...@sss.pgh.pa.us:
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
Tom Lane wrote:
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
Heikki Linnakangas escribió:
Tom Lane wrote:
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
Alvaro Herrera alvhe...@commandprompt.com writes:
Heikki Linnakangas escribió:
Tom Lane wrote:
pg_catalog | nth_value | anyelement | anyelement, integer OVER window
That looks like OVER window is associated with the integer, like
DEFAULT. I don't have any better suggestions, though.
On Wed, Dec 31, 2008 at 11:04:41AM -0500, Tom Lane wrote:
Alvaro Herrera alvhe...@commandprompt.com writes:
Heikki Linnakangas escribi�:
Tom Lane wrote:
pg_catalog | nth_value | anyelement | anyelement, integer OVER
window
That looks like OVER window is associated with the
I wrote:
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
On Tue, Dec 30, 2008 at 11:59:22AM -0500, Tom Lane wrote:
I wrote:
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
Apparently that analogy didn't impress anyone but me. AFAICT the
majority opinion is that we should use the syntax
create [or replace] [window] function ...
but just ignore the distinction between regular functions and window
functions for all other function-related SQL commands.
David Fetter da...@fetter.org writes:
Presumably psql should know about this change. Should \df now include
windowing functions along with a boolean column that indicates whether
a function is a windowing function? Should there be \dw[+] instead?
In either case, should the S option
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,
Hitoshi Harada umi.tan...@gmail.com writes:
2008/12/29 Tom Lane t...@sss.pgh.pa.us:
* Support creation of user-defined window functions. I think this is
a must have for 8.4 --- we are not in the habit of building
nonextensible basic features. It doesn't seem that hard either.
The reason I
I wrote:
* Support creation of user-defined window functions. I think this is
a must have for 8.4 --- we are not in the habit of building
nonextensible basic features. It doesn't seem that hard either.
I think all we need do is to allow WINDOW as an attribute keyword
in CREATE FUNCTION.
2008/12/29 Tom Lane t...@sss.pgh.pa.us:
I wrote:
* Support creation of user-defined window functions. I think this is
a must have for 8.4 --- we are not in the habit of building
nonextensible basic features. It doesn't seem that hard either.
I think all we need do is to allow WINDOW as an
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.
On Mon, Dec 29, 2008 at 11:59 AM, Tom Lane t...@sss.pgh.pa.us wrote:
I wrote:
* Support creation of user-defined window functions. I think this is
a must have for 8.4 --- we are not in the habit of building
nonextensible basic features. It doesn't seem that hard either.
I think all we need
I wrote:
* Investigate whether we should prohibit window functions in recursive
terms; check whether any of the committed prohibitions are unnecessary.
I looked into these questions a bit. As for the first, there doesn't
appear to be a compelling implementation reason to forbid it, and I
can't
2008/12/30 Tom Lane t...@sss.pgh.pa.us:
Hitoshi Harada umi.tan...@gmail.com writes:
And surveying sgml docs, I found this is not correct.
http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/doc/src/sgml/ref/select.sgml?r1=1.112r2=1.113
+ default framing behavior, which is equivalent to the
Andrew Dunstan and...@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
2008/12/30 Jaime Casanova jcasa...@systemguards.com.ec:
On Mon, Dec 29, 2008 at 11:59 AM, Tom Lane t...@sss.pgh.pa.us wrote:
I wrote:
* Support creation of user-defined window functions. I think this is
a must have for 8.4 --- we are not in the habit of building
nonextensible basic features.
Jaime Casanova jcasa...@systemguards.com.ec writes:
i don't understand this window function stuff well yet, but AFAIU it
is like an aggregate function that shows grouped values without
grouping rows (ok, maybe a very laizy or novice definition) but if
that is correct or near correct maybe we
2008/12/30 Tom Lane t...@sss.pgh.pa.us:
Andrew Dunstan and...@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
Hitoshi Harada umi.tan...@gmail.com writes:
2008/12/30 Tom Lane t...@sss.pgh.pa.us:
What is the difference? AFAICS the RANGE and ROWS keywords ought to be
equivalent if you are not specifying expression PRECEDING or
expression FOLLOWING.
The difference is that RANGE ... CURRENT ROW contains
2008/12/30 Tom Lane t...@sss.pgh.pa.us:
Hah, I had missed that fine point. Okay, doc is wrong and I will fix.
Given that, I think that a suitable minimum implementation should cover
both the RANGE/ROWS distinction and the CURRENT ROW/UNBOUNDED FOLLOWING
distinction, ie I would like 8.4 to
Hitoshi Harada umi.tan...@gmail.com writes:
2008/12/30 Tom Lane t...@sss.pgh.pa.us:
Is this something you're interested in working on? I can tackle it
if you don't have time now.
Sorry, over the new year days, I don't have time and will be remote.
Maybe from 3th or 4th I can work on this,
Tom Lane escribió:
The core window-functions patch is now committed and ready for wider
testing. However, there are a number of unfinished items, at least
some of which I'd like to see addressed before 8.4 release. In rough
order of importance:
[lots of discussion]
Perhaps I was a bit
On Mon, 2008-12-29 at 12:35 -0500, Tom Lane wrote:
we could lock the rows. However, consider something like this:
select x, lead(x) over() from table for update limit 1;
Because of the LIMIT, we'd only lock the first-returned row ...
but the values returned would also depend on the
The core window-functions patch is now committed and ready for wider
testing. However, there are a number of unfinished items, at least
some of which I'd like to see addressed before 8.4 release. In rough
order of importance:
* Support creation of user-defined window functions. I think this is
Tom Lane Wrote:
The core window-functions patch is now committed and ready for wider
testing. However, there are a number of unfinished items, at least
some of which I'd like to see addressed before 8.4 release. In rough
order of importance:
* Support creation of user-defined window
David Rowley dgrow...@gmail.com writes:
Unsure how difficult it is, maybe another one for a TODO, 8.4 or 8.5 I'm not
sure:
* Minimise sorts in a query such as:
I'm not tremendously excited about improving that situation. As the
code stands, the user can control what happens by ordering the
2008/12/29 Tom Lane t...@sss.pgh.pa.us:
The core window-functions patch is now committed and ready for wider
testing. However, there are a number of unfinished items, at least
some of which I'd like to see addressed before 8.4 release. In rough
order of importance:
* Support creation of
35 matches
Mail list logo
