On Fri, 2010-04-16 at 23:18 -0700, Scott Bailey wrote:
Well I've been doing a lot of work with range abstract data types in
Oracle lately. And I've got to say that the OO features in Oracle make
it really nice. Of course its Oracle, so its like a half baked OO in
cobol syntax, lol. But I
Jeff Davis wrote:
On Fri, 2010-04-09 at 12:50 -0500, Kevin Grittner wrote:
I just thought that if you were adding more type information,
oriented aournd the types themselves rather than index AMs, some form
of inheritence might fit in gracefully.
There are already some specific proposals for
Robert Haas wrote:
On Fri, Apr 9, 2010 at 11:07 AM, Yeb Havinga yebhavi...@gmail.com wrote:
From the implementers perspective, IMHO an extra catalog entry in pg_type
is not bad on its own, you would have one anyway if the range type was
explicitly programmed. About different kinds of
Robert Haas wrote:
The advantage of specifying a + and a - in the type interface is that
the unit definition can then be specified as part of the type
declaration itself. So you can do:
CREATE TYPE ts_sec AS RANGE OVER timestamp (UNIT = '1s');
CREATE TYPE ts_min AS RANGE OVER timestamp (UNIT =
Jeff Davis wrote:
To give some context, I started a thread a while ago:
http://archives.postgresql.org/pgsql-hackers/2009-10/msg01403.php
Interesting, a join type for overlaps, which makes me think a bit of the
staircase join for pre-post coordinates. However, does a join operator
type
On Sat, Apr 10, 2010 at 12:05 PM, Yeb Havinga yebhavi...@gmail.com wrote:
Jeff Davis wrote:
To give some context, I started a thread a while ago:
http://archives.postgresql.org/pgsql-hackers/2009-10/msg01403.php
Interesting, a join type for overlaps, which makes me think a bit of the
Robert Haas wrote:
On Sat, Apr 10, 2010 at 12:05 PM, Yeb Havinga yebhavi...@gmail.com wrote:
Jeff Davis wrote:
To give some context, I started a thread a while ago:
http://archives.postgresql.org/pgsql-hackers/2009-10/msg01403.php
Interesting, a join type for overlaps, which
On Sat, 2010-04-10 at 20:25 +0200, Yeb Havinga wrote:
I was thinking of a case for instance for ranges a,b,c in relations
A,B,C respectively, where a b and b c, but not a c. Would the
planner consider a join path of table A and C first, then that result
with B. After looking in doxygen,
On Fri, Apr 9, 2010 at 5:49 PM, Jeff Davis pg...@j-davis.com wrote:
On Thu, 2010-04-08 at 22:29 -0400, Robert Haas wrote:
1. knngist wants to use index scans to speed up queries of the form
SELECT ... ORDER BY column op constant (as opposed to the
existing machinery which only knows how to use
On Sat, Apr 10, 2010 at 2:30 PM, Jeff Davis pg...@j-davis.com wrote:
On Sat, 2010-04-10 at 20:25 +0200, Yeb Havinga wrote:
I was thinking of a case for instance for ranges a,b,c in relations
A,B,C respectively, where a b and b c, but not a c. Would the
planner consider a join path of table
Hi,
First, I like the way you got back to the needs before trying to
organize an approach to find a solution. Having said it allows me to cut
a lot of your text, it's the one I agree with :)
Robert Haas robertmh...@gmail.com writes:
Given a type T, I think we'd like to be able to define a type
Robert Haas wrote:
Under the first type [4pm,5pm) =
[4pm,4:59:59pm], while under the second [4pm,5pm) = [4pm,4:59pm].
Thoughts?
The examples with units look a lot like the IVLPQ datatype from HL7,
see
http://www.hl7.org/v3ballot/html/infrastructure/datatypes_r2/datatypes_r2.htm
About a
On Fri, Apr 9, 2010 at 7:55 AM, Yeb Havinga yebhavi...@gmail.com wrote:
Robert Haas wrote:
Under the first type [4pm,5pm) =
[4pm,4:59:59pm], while under the second [4pm,5pm) = [4pm,4:59pm].
Thoughts?
The examples with units look a lot like the IVLPQ datatype from HL7, see
On Fri, Apr 9, 2010 at 10:33 AM, Robert Haas robertmh...@gmail.com wrote:
On Fri, Apr 9, 2010 at 7:55 AM, Yeb Havinga yebhavi...@gmail.com wrote:
Robert Haas wrote:
Under the first type [4pm,5pm) =
[4pm,4:59:59pm], while under the second [4pm,5pm) = [4pm,4:59pm].
Thoughts?
The examples
On Fri, Apr 9, 2010 at 4:10 AM, Dimitri Fontaine dfonta...@hi-media.com wrote:
Do we want to enable support for string based ranges, as in the
contributed prefix_range type?
Yes, probably, but that doesn't require as much knowledge of the
underlying data type, so I didn't feel it needed to be
Robert Haas wrote:
On Fri, Apr 9, 2010 at 10:33 AM, Robert Haas robertmh...@gmail.com wrote:
On Fri, Apr 9, 2010 at 7:55 AM, Yeb Havinga yebhavi...@gmail.com wrote:
Robert Haas wrote:
Under the first type [4pm,5pm) =
[4pm,4:59:59pm], while under the second [4pm,5pm) =
From the implementers perspective, IMHO an extra catalog entry in
pg_type is not bad on its own, you would have one anyway if the range
type was explicitly programmed. About different kinds of range types -
I would not know how to 'promote' integer into anything else but just
one kind of
On Fri, Apr 9, 2010 at 11:07 AM, Yeb Havinga yebhavi...@gmail.com wrote:
From the implementers perspective, IMHO an extra catalog entry in pg_type
is not bad on its own, you would have one anyway if the range type was
explicitly programmed. About different kinds of range types - I would not
On 04/09/2010 07:33 AM, Robert Haas wrote:
On Fri, Apr 9, 2010 at 7:55 AM, Yeb Havinga yebhavi...@gmail.com wrote:
'tagging' a datatype as a lineair order, it could automatically have a range
type defined on it, like done for the array types currently.
The way we've handled array types is,
Robert Haas robertmh...@gmail.com wrote:
Given a type T, I think we'd like to be able to define a type U as
the natural type to be added to or subtracted from T. As Jeff
pointed out to me, this is not necessarily the same as the
underlying type. For example, if T is a timestamp, U is an
On Fri, Apr 9, 2010 at 1:13 PM, Kevin Grittner
kevin.gritt...@wicourts.gov wrote:
As it is de rigueur for someone to escalate the proposed complexity
of an idea by at least one order of magnitude, and everyone else has
fallen down on this one: ;-)
Gee, thanks for filling in?
I've often
Robert Haas robertmh...@gmail.com wrote:
I dowanna rework the type system. I'm not even 100% sure I want
to implement what I actually proposed. I do want to find out if
people think the framework makes sense and whether it's the right
way forward for those projects that need these
Robert Haas wrote:
On Fri, Apr 9, 2010 at 11:07 AM, Yeb Havinga yebhavi...@gmail.com wrote:
.. I now see the example of different ranges in your original mail with
different unit increments. Making that more general so there could be
continuous and discrete ranges and for the latter, what
On Fri, Apr 9, 2010 at 4:01 PM, Yeb Havinga yebhavi...@gmail.com wrote:
Robert Haas wrote:
On Fri, Apr 9, 2010 at 11:07 AM, Yeb Havinga yebhavi...@gmail.com wrote:
.. I now see the example of different ranges in your original mail with
different unit increments. Making that more general so
On Fri, 2010-04-09 at 12:50 -0500, Kevin Grittner wrote:
I just thought that if you were adding more type information,
oriented aournd the types themselves rather than index AMs, some form
of inheritence might fit in gracefully.
There are already some specific proposals for inheritance in
On Fri, 2010-04-09 at 11:14 -0400, Robert Haas wrote:
range of integers with increment y, if xy? Maybe the increment step and
continuous/discrete could be typmods.
Nope, not enough bits available there.
I think the problem is deeper than that. Typmods aren't carried along as
part of the
On Thu, 2010-04-08 at 22:29 -0400, Robert Haas wrote:
1. knngist wants to use index scans to speed up queries of the form
SELECT ... ORDER BY column op constant (as opposed to the
existing machinery which only knows how to use an index for SELECT ...
ORDER BY column).
2. Window functions want
On Fri, Apr 9, 2010 at 5:49 PM, Jeff Davis pg...@j-davis.com wrote:
It may or may not be worth building the concept of a unit
increment into the type interface machinery, though: one could imagine
two different range types built over the same base type with different
unit increments - e.g. one
The advantage of specifying a + and a - in the type interface is that
the unit definition can then be specified as part of the type
declaration itself. So you can do:
CREATE TYPE ts_sec AS RANGE OVER timestamp (UNIT = '1s');
CREATE TYPE ts_min AS RANGE OVER timestamp (UNIT = '1m');
All of
On Fri, Apr 9, 2010 at 7:18 PM, Nathan Boley npbo...@gmail.com wrote:
The advantage of specifying a + and a - in the type interface is that
the unit definition can then be specified as part of the type
declaration itself. So you can do:
CREATE TYPE ts_sec AS RANGE OVER timestamp (UNIT =
On Fri, Apr 9, 2010 at 7:53 PM, Robert Haas robertmh...@gmail.com wrote:
On Fri, Apr 9, 2010 at 7:18 PM, Nathan Boley npbo...@gmail.com wrote:
The advantage of specifying a + and a - in the type interface is that
the unit definition can then be specified as part of the type
declaration itself.
31 matches
Mail list logo
