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 i
Robert Haas wrote:
> On Fri, Apr 9, 2010 at 11:07 AM, Yeb Havinga 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 -
On Sat, Apr 10, 2010 at 2:30 PM, Jeff Davis 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 A an
On Fri, Apr 9, 2010 at 5:49 PM, Jeff Davis 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(as opposed to the
>> existing machinery which only knows how to use an index for SELECT ...
>>
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
Robert Haas wrote:
On Sat, Apr 10, 2010 at 12:05 PM, Yeb Havinga 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
On Sat, Apr 10, 2010 at 12:05 PM, Yeb Havinga 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
> staircase j
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 need
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 =
On Fri, Apr 9, 2010 at 7:53 PM, Robert Haas wrote:
> On Fri, Apr 9, 2010 at 7:18 PM, Nathan Boley 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:
>>>
>>> CREA
On Fri, Apr 9, 2010 at 7:18 PM, Nathan Boley 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');
>> CR
> 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');
>
>
On Fri, Apr 9, 2010 at 5:49 PM, Jeff Davis 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 timestamp
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(as opposed to the
> existing machinery which only knows how to use an index for SELECT ...
> ORDER BY ).
> 2. Window functions want to define windows
On Fri, 2010-04-09 at 11:14 -0400, Robert Haas wrote:
> > range of integers with increment y, if x<>y? 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 o
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 da
On Fri, Apr 9, 2010 at 4:01 PM, Yeb Havinga wrote:
> Robert Haas wrote:
>>
>> On Fri, Apr 9, 2010 at 11:07 AM, Yeb Havinga 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
>>> contin
Robert Haas wrote:
On Fri, Apr 9, 2010 at 11:07 AM, Yeb Havinga 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 would the increment
be.
Robert Haas 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 features.
What you propo
On Fri, Apr 9, 2010 at 1:13 PM, Kevin Grittner
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 thought that if we rework th
Robert Haas 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
> interval; if T i
On 04/09/2010 07:33 AM, Robert Haas wrote:
> On Fri, Apr 9, 2010 at 7:55 AM, Yeb Havinga 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, quite frankly,
On Fri, Apr 9, 2010 at 11:07 AM, Yeb Havinga 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
>> know how to '
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 'ran
Robert Haas wrote:
On Fri, Apr 9, 2010 at 10:33 AM, Robert Haas wrote:
On Fri, Apr 9, 2010 at 7:55 AM, Yeb Havinga 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 wi
On Fri, Apr 9, 2010 at 4:10 AM, Dimitri Fontaine 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 brought up in
this con
On Fri, Apr 9, 2010 at 10:33 AM, Robert Haas wrote:
> On Fri, Apr 9, 2010 at 7:55 AM, Yeb Havinga 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
On Fri, Apr 9, 2010 at 7:55 AM, Yeb Havinga 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 IVL datatype from HL7, see
> http://www.hl7.org/v3b
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 IVL datatype from HL7,
see
http://www.hl7.org/v3ballot/html/infrastructure/datatypes_r2/datatypes_r2.htm
About a type
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 writes:
> Given a type T, I think we'd like to be able to define a type U as
> "the natural t
There are a couple of features that were considered but not committed
for 9.0 which require additional information about the properties of
various data types. At PGeast I had a chance to talk with Jeff Davis
about this briefly, and wanted to write up some of what we talked
about plus some further
32 matches
Mail list logo
