Re: Support for RANGE ... PRECEDING windows in OVER - Mailing list pgsql-hackers

From Alvaro Herrera
Subject Re: Support for RANGE ... PRECEDING windows in OVER
Date
Msg-id 20130701192842.GM3757@eldon.alvh.no-ip.org
Whole thread Raw
In response to Re: Support for RANGE ... PRECEDING windows in OVER  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: Support for RANGE ... PRECEDING windows in OVER  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
Robert Haas escribió:
> On Sun, Jun 30, 2013 at 11:54 PM, ian link <ian@ilink.io> wrote:

> > It seems pretty clear that assuming '+' and '-' are addition and subtraction
> > is a bad idea. I don't think it would be too tricky to add support for new
> > operator strategies. Andrew Gierth suggested calling these new strategies
> > "offset -" and "offset +", which I think describes it pretty well. I
> > assigned the operator itself to be "@+" and "@-" but that can obviously be
> > changed. If this sounds like a good path to you guys, I will go ahead and
> > implement the operators for the appropriate types. Please let me know if I
> > am misunderstanding something - I am still figuring stuff out :)
> 
> I don't think I understand the design you have in mind.  I'm actually
> not clear that it would be all that bad to assume fixed operator
> names, as we apparently do in a few places despite the existence of
> operator classes.  But if that is bad, then I don't know how using @+
> and @- instead helps anything.

Yeah.

Currently, all operator classes are tied to access methods.  Since
nobody seems to have any great idea about creating an access method that
requires addition and subtraction, would it make sense to have operator
classes that exist solely to support keeping track of such operators for
the various datatypes?

-- 
Álvaro Herrera                http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services



pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: Documentation/help for materialized and recursive views
Next
From: Robert Haas
Date:
Subject: Re: Randomisation for ensuring nlogn complexity in quicksort