2009/2/5 Bruce Momjian :
> 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 t
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
> > +---
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
> > +---
> 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 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 functions "seeing"
On Wed, Dec 31, 2008 at 11:04:41AM -0500, Tom Lane wrote:
> Alvaro Herrera 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
Alvaro Herrera 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.
> pg_ca
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
>>
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
+---+--+-
2008/12/31 Tom Lane :
> "Robert Haas" 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 marginal
"Robert Haas" 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 co
David Fetter 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 indicating "include s
> 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 comman
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 a
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
> di
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
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 h
"Hitoshi Harada" writes:
> 2008/12/30 Tom Lane :
>> 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, so if you have time during
> ti
2008/12/30 Tom Lane :
> 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 support
>
>
"Hitoshi Harada" writes:
> 2008/12/30 Tom Lane :
>> 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 all peers of the
> curre
2008/12/30 Tom Lane :
> Andrew Dunstan 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 pr
"Jaime Casanova" 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 need to follow the same
2008/12/30 Jaime Casanova :
> On Mon, Dec 29, 2008 at 11:59 AM, Tom Lane 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 eithe
Andrew Dunstan 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 WINDO
2008/12/30 Tom Lane :
> "Hitoshi Harada" 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.112&r2=1.113
>
>> + default framing behavior, which is equivalent to the framing clause
>> + ROWS
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'
On Mon, Dec 29, 2008 at 11:59 AM, Tom Lane 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 do is to
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.
2008/12/29 Tom Lane :
> 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 attribu
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 FUNCT
"Hitoshi Harada" writes:
> 2008/12/29 Tom Lane :
>> * 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 and people decided window f
2008/12/29 Tom Lane :
> 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 wi
"David Rowley" 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 WINDOW
clause ap
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
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
35 matches
Mail list logo
