Re: [HACKERS] WIP: Range Types

On Wed, Jan 12, 2011 at 2:52 PM, Tom Lane wrote: > Robert Haas writes: >> On Wed, Jan 12, 2011 at 2:35 PM, Tom Lane wrote: >>> The general point is that any out-of-band data transmitted to an output >>> function has to be trustworthy, and it has to be available at any place >>> that is going to

Re: [HACKERS] WIP: Range Types

Robert Haas writes: > On Wed, Jan 12, 2011 at 2:35 PM, Tom Lane wrote: >> The general point is that any out-of-band data transmitted to an output >> function has to be trustworthy, and it has to be available at any place >> that is going to call the output function.  The latter point tends to >>

Re: [HACKERS] WIP: Range Types

On Wed, Jan 12, 2011 at 2:35 PM, Tom Lane wrote: > Alvaro Herrera writes: >> Excerpts from Robert Haas's message of mié ene 12 13:48:27 -0300 2011: >>> I guess that begs the question of why we need to allow users to call >>> type output functions directly. > >> It used to be the case that that wa

Re: [HACKERS] WIP: Range Types

Alvaro Herrera writes: > Excerpts from Robert Haas's message of mié ene 12 13:48:27 -0300 2011: >> I guess that begs the question of why we need to allow users to call >> type output functions directly. > It used to be the case that that was the only way to run certain casts. > For example, see

Re: [HACKERS] WIP: Range Types

Excerpts from Robert Haas's message of mié ene 12 13:48:27 -0300 2011: > I guess that begs the question of why we need to allow users to call > type output functions directly. It used to be the case that that was the only way to run certain casts. For example, see the pre-8.2 version of this: htt

Re: [HACKERS] WIP: Range Types

On Jan 12, 2011, at 8:48 AM, Robert Haas wrote: > I guess that begs the question of why we need to allow users to call > type output functions directly. I've used them quite a lot in the past; less so on 8.4+ where casting everything to text became a lot easier. Best, David -- Sent via pgsq

Re: [HACKERS] WIP: Range Types

On Wed, Jan 12, 2011 at 2:16 AM, Martijn van Oosterhout wrote: > On Tue, Jan 11, 2011 at 09:24:08PM -0500, Robert Haas wrote: >> commit 6c412f0605afeb809014553ff7ad28cf9ed5526b >> Author: Tom Lane >> Date:   Sun May 1 18:56:19 2005 + >> >>     Change CREATE TYPE to require datatype output and

Re: [HACKERS] WIP: Range Types

On Tue, Jan 11, 2011 at 09:24:08PM -0500, Robert Haas wrote: > commit 6c412f0605afeb809014553ff7ad28cf9ed5526b > Author: Tom Lane > Date: Sun May 1 18:56:19 2005 + > > Change CREATE TYPE to require datatype output and send functions to have > only one argument. (Per recent discussi

Re: [HACKERS] WIP: Range Types

On Sun, Jan 9, 2011 at 4:03 AM, Jeff Davis wrote: > It also might be worth figuring out why input functions get the type oid > and output functions do not. I see this comment above getTypeIOParam(): > >  * As of PostgreSQL 8.1, output functions receive only the value > itself >  * and not any auxi

Re: [HACKERS] WIP: Range Types

On Sat, 2011-01-08 at 21:58 -0500, Robert Haas wrote: > I mean, one semi-obvious possibility is to write one set of C > functions that can have multiple SQL-level definitions bound to it. > Then when the function is called, it can peek at flinfo->fn_oid to > figure out which incarnation was called

Re: [HACKERS] WIP: Range Types

On Sat, Jan 8, 2011 at 9:12 PM, Jeff Davis wrote: >> Oh, hmm.  What generic functions did you have in mind? > > Well, input/output, comparisons, overlaps, intersection, minus, and all > the necessary GiST support functions. > > Without generic functions, the only choices we have are: >  * force th

Re: [HACKERS] WIP: Range Types

On Sat, 2011-01-08 at 20:32 -0500, Robert Haas wrote: > On Sat, Jan 8, 2011 at 4:05 PM, Jeff Davis wrote: > > On Sat, 2011-01-08 at 15:47 -0500, Robert Haas wrote: > >> On Sat, Jan 8, 2011 at 3:12 PM, Jeff Davis wrote: > >> > Any ideas? Maybe, with alignment and a "flags" byte (to hold > >> > inc

Re: [HACKERS] WIP: Range Types

On Sat, Jan 8, 2011 at 6:06 PM, Jeff Davis wrote: > If we use timestamps, then that's 8 bytes each, meaning 16 bytes. Then, > there is the VARHDRSZ (now we're at 20), the flag byte (21), and the > range type oid (25). With alignment (if it's aligned at all), that's > either 28 or 32 bytes, which i

Re: [HACKERS] WIP: Range Types

On Sat, Jan 8, 2011 at 4:05 PM, Jeff Davis wrote: > On Sat, 2011-01-08 at 15:47 -0500, Robert Haas wrote: >> On Sat, Jan 8, 2011 at 3:12 PM, Jeff Davis wrote: >> > Any ideas? Maybe, with alignment and a "flags" byte (to hold >> > inclusivity, infinite boundaries, etc.), the extra 4 bytes doesn't

Re: [HACKERS] WIP: Range Types

On Sat, 2011-01-08 at 13:05 -0800, Jeff Davis wrote: > On Sat, 2011-01-08 at 15:47 -0500, Robert Haas wrote: > > On Sat, Jan 8, 2011 at 3:12 PM, Jeff Davis wrote: > > > Any ideas? Maybe, with alignment and a "flags" byte (to hold > > > inclusivity, infinite boundaries, etc.), the extra 4 bytes doe

Re: [HACKERS] WIP: Range Types

On Sat, 2011-01-08 at 15:47 -0500, Robert Haas wrote: > On Sat, Jan 8, 2011 at 3:12 PM, Jeff Davis wrote: > > Any ideas? Maybe, with alignment and a "flags" byte (to hold > > inclusivity, infinite boundaries, etc.), the extra 4 bytes doesn't cost > > much, anyway? > > I'd be really reluctant to b

Re: [HACKERS] WIP: Range Types

On Sat, Jan 8, 2011 at 3:12 PM, Jeff Davis wrote: > Any ideas? Maybe, with alignment and a "flags" byte (to hold > inclusivity, infinite boundaries, etc.), the extra 4 bytes doesn't cost > much, anyway? I'd be really reluctant to bloat the range representation by 4 bytes to support an anyrange ty

Re: [HACKERS] WIP: Range Types

When writing the generic range output function, it needs to know the specific range type in order to call the subtype's output function. Records accomplish this by using a special cache based on the typmod, apparently, which looks like a hack to me. Arrays accomplish this by storing the specific

Re: [HACKERS] WIP: Range Types

On Fri, 2011-01-07 at 08:21 +, Florian Weimer wrote: > > > I'm wondering if one of these hint functions can be reused to compute > range lengths. Interesting idea. However, I don't really see a way to make that work. These f

Re: [HACKERS] WIP: Range Types

* Jeff Davis: > On Tue, 2011-01-04 at 14:18 +, Florian Weimer wrote: >> * Jeff Davis: >> >> > 4. For the GiST penalty function, and perhaps some picksplit algorithms, >> > it might be nice to know the length of a range, or do some other kinds >> > of math. It introduces a lot of complexity to

Re: [HACKERS] WIP: Range Types

On Thu, Jan 6, 2011 at 12:32 PM, Jeff Davis wrote: > On Wed, 2011-01-05 at 12:07 -0800, Jeff Davis wrote: >> The current design for range types doesn't ask for add or subtract. >> Although it might be interesting to try to use such an interface for >> range types, it introduces a lot of complexity

Re: [HACKERS] WIP: Range Types

On Wed, 2011-01-05 at 12:07 -0800, Jeff Davis wrote: > The current design for range types doesn't ask for add or subtract. > Although it might be interesting to try to use such an interface for > range types, it introduces a lot of complexity and makes it easier to > cause subtle problems (consider

Re: [HACKERS] WIP: Range Types

On Thu, 2011-01-06 at 09:30 +0900, Hitoshi Harada wrote: > Robert Haas originally began to propose the idea of type > interface to get together three of KNN-GIST, range type and window > frame issue. For KNN-GIST, it was committed by extending pg_amop > without considering others and range type wil

Re: [HACKERS] WIP: Range Types

2011/1/6 Jeff Davis : > Even if add and subtract were associated with a range type, there's no > way to tell which range type to pick given the window function syntax > (multiple range types could be defined over the same subtype). > > I think the interface question should be addressed more directl

Re: [HACKERS] WIP: Range Types

On Wed, 2011-01-05 at 10:41 -0800, David Fetter wrote: > On Thu, Jan 06, 2011 at 02:25:01AM +0900, Hitoshi Harada wrote: > > For any type to calculate boundary based on RANGE clause in window > > functions, we need some type interface mechanism in the core to know > > how to add / subtract values t

Re: [HACKERS] WIP: Range Types

On Thu, Jan 06, 2011 at 02:25:01AM +0900, Hitoshi Harada wrote: > 2011/1/5 Jeff Davis : > > On Tue, 2011-01-04 at 23:04 +0900, Hitoshi Harada wrote: > >> >  CREATE TYPE numrange > >> >    AS RANGE (SUBTYPE=numeric, SUBTYPE_CMP=numeric_cmp); > >> > >> I am interested in how you define increment/decr

Re: [HACKERS] WIP: Range Types

2011/1/5 Jeff Davis : > On Tue, 2011-01-04 at 23:04 +0900, Hitoshi Harada wrote: >> >  CREATE TYPE numrange >> >    AS RANGE (SUBTYPE=numeric, SUBTYPE_CMP=numeric_cmp); >> >> I am interested in how you define increment/decrement operation of >> range value in discrete types. The window functions an

Re: [HACKERS] WIP: Range Types

2011/1/5 Jeff Davis : > On Tue, 2011-01-04 at 23:04 +0900, Hitoshi Harada wrote: >> >  CREATE TYPE numrange >> >    AS RANGE (SUBTYPE=numeric, SUBTYPE_CMP=numeric_cmp); >> >> I am interested in how you define increment/decrement operation of >> range value in discrete types. The window functions an

Re: [HACKERS] WIP: Range Types

On Wed, Jan 5, 2011 at 12:54 AM, Jeff Davis wrote: > On Tue, 2011-01-04 at 16:45 -0800, Josh Berkus wrote: >> On 1/4/11 10:18 AM, Jeff Davis wrote: >> > The main drawback here is that only a select group of people will be >> > defining discrete range types at all, because it would require them to

Re: [HACKERS] WIP: Range Types

On Tue, 2011-01-04 at 16:45 -0800, Josh Berkus wrote: > On 1/4/11 10:18 AM, Jeff Davis wrote: > > The main drawback here is that only a select group of people will be > > defining discrete range types at all, because it would require them to > > define a function first. Perhaps that's for the best,

Re: [HACKERS] WIP: Range Types

On 1/4/11 10:18 AM, Jeff Davis wrote: > The main drawback here is that only a select group of people will be > defining discrete range types at all, because it would require them to > define a function first. Perhaps that's for the best, because, (as Tom > pointed out) we don't want someone using f

Re: [HACKERS] WIP: Range Types

On Tue, Jan 4, 2011 at 1:18 PM, Jeff Davis wrote: > On Tue, 2011-01-04 at 12:21 -0500, Robert Haas wrote: >> > It doesn't allow for all of the suggested features. In particular, it >> > would not allow "granules" to be specified for discrete ranges. But on >> > balance, it seems like this is the m

Re: [HACKERS] WIP: Range Types

On Tue, 2011-01-04 at 23:04 +0900, Hitoshi Harada wrote: > 2011/1/4 Jeff Davis : > > I have been updating my work in progress here: > > > > http://git.postgresql.org/gitweb?p=users/jdavis/postgres.git;a=log;h=refs/heads/rangetypes > > > > Right now, it's not in a reviewable state, but those interes

Re: [HACKERS] WIP: Range Types

On Tue, 2011-01-04 at 14:18 +, Florian Weimer wrote: > * Jeff Davis: > > > 4. For the GiST penalty function, and perhaps some picksplit algorithms, > > it might be nice to know the length of a range, or do some other kinds > > of math. It introduces a lot of complexity to try to define math >

Re: [HACKERS] WIP: Range Types

On Tue, 2011-01-04 at 12:21 -0500, Robert Haas wrote: > > It doesn't allow for all of the suggested features. In particular, it > > would not allow "granules" to be specified for discrete ranges. But on > > balance, it seems like this is the most conceptually simple and I think > > it satisfies the

Re: [HACKERS] WIP: Range Types

On Tue, Jan 4, 2011 at 2:29 AM, Jeff Davis wrote: > I liked Robert's suggestion here: > > http://archives.postgresql.org/message-id/aanlktiks_x93_k82b4f_ga634wci0oeb9ftrurf28...@mail.gmail.com > > which says that the user can just define a "canonicalize" function that > will take a range as input

Re: [HACKERS] WIP: Range Types

Jeff Davis writes: > 2. We need to use the subtype's IO functions, but those may not be > immutable. So, rather than create new IO functions for each range type, > I was thinking that I'd use just three (anyrange_i_in, anyrange_s_in, > and anyrange_v_in), and select the right one at definition tim

Re: [HACKERS] WIP: Range Types

* Jeff Davis: > 4. For the GiST penalty function, and perhaps some picksplit algorithms, > it might be nice to know the length of a range, or do some other kinds > of math. It introduces a lot of complexity to try to define math > functions for each subtype, and try to make sure they behave sanely

Re: [HACKERS] WIP: Range Types

2011/1/4 Jeff Davis : > I have been updating my work in progress here: > > http://git.postgresql.org/gitweb?p=users/jdavis/postgres.git;a=log;h=refs/heads/rangetypes > > Right now, it's not in a reviewable state, but those interested can > glance through the code. > > Quick synopsis (for illustrati

[HACKERS] WIP: Range Types

I have been updating my work in progress here: http://git.postgresql.org/gitweb?p=users/jdavis/postgres.git;a=log;h=refs/heads/rangetypes Right now, it's not in a reviewable state, but those interested can glance through the code. Quick synopsis (for illustration purposes only; don't expect much