Re: GiST for range types (was Re: [HACKERS] Range Types - typo + NULL string constructor)

Alexander Korotkov writes: > On Mon, Jan 30, 2012 at 1:39 AM, Jeff Davis wrote: >> Marking "ready for committer", but please apply my comment fixes at your >> discretion. > Patch with your comment fixes is attached. Applied with revisions, some cosmetic, some not so much.

Re: GiST for range types (was Re: [HACKERS] Range Types - typo + NULL string constructor)

On Mon, Jan 30, 2012 at 1:39 AM, Jeff Davis wrote: > Thank you for the updates. I have a small patch attached. > > The only code change I made was very minor: I changed the constants used > in the penalty function because your version used INFINITE_BOUND_PENALTY > when adding an empty range, and

Re: GiST for range types (was Re: [HACKERS] Range Types - typo + NULL string constructor)

On Tue, 2012-01-24 at 16:07 +0400, Alexander Korotkov wrote: > Hi! > > > New version of patch is attached. Thank you for the updates. I have a small patch attached. The only code change I made was very minor: I changed the constants used in the penalty function because your version used INFINIT

Re: GiST for range types (was Re: [HACKERS] Range Types - typo + NULL string constructor)

Hi! New version of patch is attached. On Thu, Dec 22, 2011 at 11:46 AM, Jeff Davis wrote: > A few comments: > > * In range_gist_picksplit, it would be nice to have a little bit more > intuitive description of what's going on with the nonEmptyCount and > nonInfCount numbers. For instance, it appe

Re: GiST for range types (was Re: [HACKERS] Range Types - typo + NULL string constructor)

On Tue, 2011-12-20 at 13:22 +0400, Alexander Korotkov wrote: > Hi! > > > Studying this question little more I found that current approach of > range indexing can be dramatically inefficient in some cases. It's not > because of penalty or split implementation, but because of approach > itself. Map

Re: GiST for range types (was Re: [HACKERS] Range Types - typo + NULL string constructor)

On Wed, 2011-12-14 at 01:04 +0400, Alexander Korotkov wrote: > Hi! > Thank you! Attached a few changes: * Change "ordinal" to "normal" for clarity (at least to me). * Some comment cleanup * Change classes_groups to be an enum of SPLIT_LEFT and SPLIT_RIGHT, rather than using 1 and 2. * Changed the

Re: GiST for range types (was Re: [HACKERS] Range Types - typo + NULL string constructor)

Hi! Studying this question little more I found that current approach of range indexing can be dramatically inefficient in some cases. It's not because of penalty or split implementation, but because of approach itself. Mapping intervals to two-dimensional space produce much better results in case

Re: GiST for range types (was Re: [HACKERS] Range Types - typo + NULL string constructor)

On 12/13/2011 04:04 PM, Alexander Korotkov wrote: On Mon, Dec 12, 2011 at 10:41 PM, Jeff Davis > wrote: * There's a lot of code for range_gist_penalty. Rather than having special cases for all combinations of properties in the new an original, is it poss

Re: GiST for range types (was Re: [HACKERS] Range Types - typo + NULL string constructor)

On Sat, Dec 10, 2011 at 6:14 PM, Greg Smith wrote: > On 12/02/2011 06:48 AM, Alexander Korotkov wrote: > >> Rebased with head. >> > > Could you comment a little more on what changed? There were a couple of > areas Tom commented on: > > -General code fixes > Expensibe usage of "Max" macro is fix

Re: GiST for range types (was Re: [HACKERS] Range Types - typo + NULL string constructor)

Hi! On Mon, Dec 12, 2011 at 10:41 PM, Jeff Davis wrote: > Thank you. I have attached a patch that's mostly just cleanup to this > one. > Thanks a lot for cleanup. Path with applied cleanup is attached. > Comments: > > * You use the term "ordinal range" quite a lot, which I haven't heard > befo

Re: GiST for range types (was Re: [HACKERS] Range Types - typo + NULL string constructor)

On Fri, 2011-12-02 at 15:48 +0400, Alexander Korotkov wrote: > Rebased with head. > Thank you. I have attached a patch that's mostly just cleanup to this one. Comments: * You use the term "ordinal range" quite a lot, which I haven't heard before. Is that a mathematical term, or do you mean somet

Re: GiST for range types (was Re: [HACKERS] Range Types - typo + NULL string constructor)

On 12/02/2011 06:48 AM, Alexander Korotkov wrote: Rebased with head. Could you comment a little more on what changed? There were a couple of areas Tom commented on: -General code fixes -"pull out and apply the changes related to the RANGE_CONTAIN_EMPTY flag, and also remove the <> opclass

Re: GiST for range types (was Re: [HACKERS] Range Types - typo + NULL string constructor)

Rebased with head. -- With best regards, Alexander Korotkov. rangetypegist-0.4.patch.gz Description: GNU Zip compressed data -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

Re: GiST for range types (was Re: [HACKERS] Range Types - typo + NULL string constructor)

On Mon, Nov 28, 2011 at 3:00 AM, Tom Lane wrote: > I see your point that we only need the penalty values to be comparable > for the same "new" value, but I don't think that really answers my > objection, because you've had to lobotomize the logic. As an example, > if we have a new empty range to

Re: GiST for range types (was Re: [HACKERS] Range Types - typo + NULL string constructor)

Alexander Korotkov writes: > On Sun, Nov 27, 2011 at 10:43 PM, Tom Lane wrote: >> 1. penalty is using both hard-wired penalty values (1.0, 2.0, etc) and >> values obtained from subtype_diff. This is not good, because you have >> no idea what scale the subtype differences will be expressed on. T

Re: GiST for range types (was Re: [HACKERS] Range Types - typo + NULL string constructor)

On Sun, Nov 27, 2011 at 10:43 PM, Tom Lane wrote: > > 1. penalty is using both hard-wired penalty values (1.0, 2.0, etc) and > values obtained from subtype_diff. This is not good, because you have > no idea what scale the subtype differences will be expressed on. The > hard-wired values could be

Re: GiST for range types (was Re: [HACKERS] Range Types - typo + NULL string constructor)

Alexander Korotkov writes: > On Sat, Nov 26, 2011 at 11:11 AM, Jeff Davis wrote: >> There's been some significant change in rangetypes_gist.c, can you >> please rebase this patch? > OK, rebased with head. I looked at this patch a bit. I agree with the aspect of it that says "let's add a flag b

Re: GiST for range types (was Re: [HACKERS] Range Types - typo + NULL string constructor)

On Sat, Nov 26, 2011 at 11:11 AM, Jeff Davis wrote: > > There's been some significant change in rangetypes_gist.c, can you > please rebase this patch? > OK, rebased with head. -- With best regards, Alexander Korotkov. rangetypegist-0.3.patch.gz Description: GNU Zip compressed data -- Sent

Re: GiST for range types (was Re: [HACKERS] Range Types - typo + NULL string constructor)

On Wed, 2011-11-09 at 20:24 +0400, Alexander Korotkov wrote: > New version of GiST for range types patch is here. This version seems > to be complete and ready for review. > There's been some significant change in rangetypes_gist.c, can you please rebase this patch? I like the patch conceptually,

Re: GiST for range types (was Re: [HACKERS] Range Types - typo + NULL string constructor)

On 07.11.2011 20:36, Tom Lane wrote: Alexander Korotkov writes: So, !? and ? operators are mentioned in documentation, but don't present in catalog. Are them just missed in the catalog or there is some more serious problem? IIRC, Heikki removed them from the final commit. Sounds like he miss

Re: GiST for range types (was Re: [HACKERS] Range Types - typo + NULL string constructor)

First version of GiST for range types patch is here. Comments & refactoring & testing are coming soon. -- With best regards, Alexander Korotkov. rangetypegist-0.1.patch.gz Description: GNU Zip compressed data -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make cha

Re: GiST for range types (was Re: [HACKERS] Range Types - typo + NULL string constructor)

Alexander Korotkov writes: > So, !? and ? operators are mentioned in documentation, but don't present in > catalog. Are them just missed in the catalog or there is some more serious > problem? IIRC, Heikki removed them from the final commit. Sounds like he missed some documentation.

Re: GiST for range types (was Re: [HACKERS] Range Types - typo + NULL string constructor)

During work on gist for range types I've faced with following problem: test=# select 'empty'::int4range !?; ERROR: operator does not exist: int4range !? LINE 1: select 'empty'::int4range !?; ^ HINT: No operator matches the given name and argument type(s). You mi

Re: GiST for range types (was Re: [HACKERS] Range Types - typo + NULL string constructor)

On Wed, 2011-11-02 at 22:59 +0200, Heikki Linnakangas wrote: > This seems to be coming from the selectivity estimation function. The > selectivity function for <@ is scalargtsel, which is usually used for > scalar > and >=. That doesn't seem right. But what do we store in the > statistics for ra

Re: GiST for range types (was Re: [HACKERS] Range Types - typo + NULL string constructor)

On Wed, 2011-11-02 at 21:29 +0200, Heikki Linnakangas wrote: > > + else if (lower1.infinite || upper1.infinite) > > + length1 = 1.0/0.0; > > That seems wrong. I take it that the point is to set length1 to infinity? I reworked this in commit (on my private repo, of course): 619

Re: [HACKERS] Range Types - typo + NULL string constructor

On Thu, 2011-11-03 at 10:37 +0200, Heikki Linnakangas wrote: > Looking at the most recent patch, I don't actually see any GiST support > for the empty and non-empty operators (!? and ?). I don't see how those > could be accelerated with GiST, anyway; I think if you want to use an > index for tho

Re: GiST for range types (was Re: [HACKERS] Range Types - typo + NULL string constructor)

On Thu, Nov 3, 2011 at 3:59 PM, Heikki Linnakangas < heikki.linnakan...@enterprisedb.com> wrote: > I've committed this now, after some more cleanup. I removed the > selectivity estimation functions from operators where they were bogus, so > writing those is a clear TODO. But that can well be done

Re: GiST for range types (was Re: [HACKERS] Range Types - typo + NULL string constructor)

On Nov3, 2011, at 18:54 , David E. Wheeler wrote: > On Nov 3, 2011, at 4:59 AM, Heikki Linnakangas wrote: >> I've committed this now, after some more cleanup. I removed the selectivity >> estimation functions from operators where they were bogus, so writing those >> is a clear TODO. But that can

Re: GiST for range types (was Re: [HACKERS] Range Types - typo + NULL string constructor)

On Nov 3, 2011, at 4:59 AM, Heikki Linnakangas wrote: > I've committed this now, after some more cleanup. I removed the selectivity > estimation functions from operators where they were bogus, so writing those > is a clear TODO. But that can well be done as a separate patch. > > Thanks! Woo! C

Re: GiST for range types (was Re: [HACKERS] Range Types - typo + NULL string constructor)

On 03.11.2011 10:42, Jeff Davis wrote: On Wed, 2011-11-02 at 22:59 +0200, Heikki Linnakangas wrote: This seems to be coming from the selectivity estimation function. The selectivity function for<@ is scalargtsel, which is usually used for scalar> and>=. That doesn't seem right. But what do we s

Re: [HACKERS] Range Types - typo + NULL string constructor

On 17.10.2011 01:09, Jeff Davis wrote: On Sat, 2011-10-15 at 01:46 +0300, Heikki Linnakangas wrote: * Do we really need non_empty(anyrange) ? You can just do "NOT empty(x)" To make it a searchable (via GiST) condition, I need an operator. I could either remove that operator (as it's not amazin

Re: GiST for range types (was Re: [HACKERS] Range Types - typo + NULL string constructor)

On 02.11.2011 22:59, Heikki Linnakangas wrote: I'll dig deeper into this tomorrow... Forgot to mention: I have pushed what I have done this far to my git repository at git://git.postgresql.org/git/users/heikki/postgres.git, if you want to take a look. Nothing major, just garden-variety cleanu

Re: GiST for range types (was Re: [HACKERS] Range Types - typo + NULL string constructor)

On 01.11.2011 06:33, Jeff Davis wrote: On Mon, 2011-10-24 at 15:05 +0400, Alexander Korotkov wrote: I think implementing subtype_diff for each datatype is ok. We could implement some universal function based on minus operator and casting to double precision. But such solution might be unaccept

Re: GiST for range types (was Re: [HACKERS] Range Types - typo + NULL string constructor)

Heikki Linnakangas writes: > On 01.11.2011 06:33, Jeff Davis wrote: >> + else if (lower1.infinite || upper1.infinite) >> + length1 = 1.0/0.0; > That seems wrong. I take it that the point is to set length1 to infinity? Please use get_float[48]_infinity() or get_float[48]_nan()

Re: GiST for range types (was Re: [HACKERS] Range Types - typo + NULL string constructor)

On 01.11.2011 06:33, Jeff Davis wrote: On Mon, 2011-10-24 at 15:05 +0400, Alexander Korotkov wrote: I think implementing subtype_diff for each datatype is ok. We could implement some universal function based on minus operator and casting to double precision. But such solution might be unaccept

Re: [HACKERS] Range Types - typo + NULL string constructor

Robert Haas writes: > I believe that we're in trouble with XIDs as soon as you have two > active XIDs that are separated by a billion, because then you could > have a situation where some people think a given XID is in the future > and others think it's in the past. I have been wondering if we sh

Re: [HACKERS] Range Types - typo + NULL string constructor

Heikki Linnakangas writes: > That's not what Jeff is referring to here, though (correct me if I'm > wrong). He's talking about the one-item cache in > TransactionIdLogFetch(). You don't need need long-running transactions > for that to get confused. Specifically, this could happen: > 1. In ses

Re: [HACKERS] Range Types - typo + NULL string constructor

On Wed, 2011-10-26 at 12:19 -0400, Robert Haas wrote: > > 1. In session A: BEGIN; SELECT * FROM foo WHERE id = 1; COMMIT; > > The row has xmin = 123456, and it is cached as committed in the one-item > > cache by TransactionLogFetch. > > 2. A lot of time passes. Everything is frozen, and XID wrap-

Re: [HACKERS] Range Types - typo + NULL string constructor

Excerpts from Robert Haas's message of mié oct 26 13:19:47 -0300 2011: > On Wed, Oct 26, 2011 at 11:52 AM, Heikki Linnakangas > wrote: > > 1. In session A: BEGIN; SELECT * FROM foo WHERE id = 1; COMMIT; > >   The row has xmin = 123456, and it is cached as committed in the one-item > > cache by T

Re: [HACKERS] Range Types - typo + NULL string constructor

On Wed, Oct 26, 2011 at 11:52 AM, Heikki Linnakangas wrote: > On 26.10.2011 18:42, Robert Haas wrote: >> >> On Tue, Oct 25, 2011 at 12:37 PM, Jeff Davis  wrote: >>> >>> Aren't there a few other cases like this floating around the code? I >>> know the single-xid cache is potentially vulnerable to x

Re: [HACKERS] Range Types - typo + NULL string constructor

On 26.10.2011 18:42, Robert Haas wrote: On Tue, Oct 25, 2011 at 12:37 PM, Jeff Davis wrote: Aren't there a few other cases like this floating around the code? I know the single-xid cache is potentially vulnerable to xid wraparound for the same reason. I believe that we're in trouble with XIDs

Re: [HACKERS] Range Types - typo + NULL string constructor

On Tue, Oct 25, 2011 at 12:37 PM, Jeff Davis wrote: > On Mon, 2011-10-24 at 13:15 +0300, Heikki Linnakangas wrote: >> Hmm, I don't think that's safe. After Oid wraparound, a range type oid >> might get reused for some other range type, and the cache would return >> stale values. Extremely unlikely

Re: [HACKERS] Range Types - typo + NULL string constructor

On 25.10.2011 19:37, Jeff Davis wrote: On Mon, 2011-10-24 at 13:15 +0300, Heikki Linnakangas wrote: Hmm, I don't think that's safe. After Oid wraparound, a range type oid might get reused for some other range type, and the cache would return stale values. Extremely unlikely to happen by accident

Re: GiST for range types (was Re: [HACKERS] Range Types - typo + NULL string constructor)

On Mon, Oct 24, 2011 at 3:05 PM, Alexander Korotkov wrote: > If we allow user to specify own gist_penalty function, then such function > should deal with: > 1) GiST-specific data structures such as GISTENTRY. > 2) Decomposing ranges using range_deserialize. > 3) Inifinities, which we could handle

Re: [HACKERS] Range Types - typo + NULL string constructor

On Mon, 2011-10-24 at 13:15 +0300, Heikki Linnakangas wrote: > Hmm, I don't think that's safe. After Oid wraparound, a range type oid > might get reused for some other range type, and the cache would return > stale values. Extremely unlikely to happen by accident, but could be > exploited by an

Re: [HACKERS] Range Types - typo + NULL string constructor

On 17.10.2011 01:09, Jeff Davis wrote: On Sat, 2011-10-15 at 01:46 +0300, Heikki Linnakangas wrote: * The binary i/o format includes the length of the lower and upper bounds twice, once explicitly in range_send, and second time within the send-function of the subtype. Seems wasteful. Any ideas

Re: GiST for range types (was Re: [HACKERS] Range Types - typo + NULL string constructor)

Hi! On Mon, Oct 17, 2011 at 12:38 PM, Jeff Davis wrote: > > I started implementing subtype_diff, and I noticed that it requires > > defining an extra function for each range type. Previously, the numeric > > types could just use a cast, which was convenient for user-defined range > > types. > >

Re: [HACKERS] Range Types - typo + NULL string constructor

On Mon, October 17, 2011 00:09, Jeff Davis wrote: To facilitate would-be testers let me mention that to apply this patch one needs to remove the catversion changes from the patch. (as discussed before: http://archives.postgresql.org/pgsql-hackers/2011-02/msg00817.php ) Erik Rijkers -- Se

Re: GiST for range types (was Re: [HACKERS] Range Types - typo + NULL string constructor)

On Sun, 2011-10-16 at 14:43 -0700, Jeff Davis wrote: > On Fri, 2011-10-07 at 12:54 +0400, Alexander Korotkov wrote: > > > The first thing caught my eye in existing GiST code is idea of > > subtype_float. float8 has limited precision and can't respresent, for > > example, varlena values good enough

Re: GiST for range types (was Re: [HACKERS] Range Types - typo + NULL string constructor)

On Fri, 2011-10-07 at 12:54 +0400, Alexander Korotkov wrote: > The first thing caught my eye in existing GiST code is idea of > subtype_float. float8 has limited precision and can't respresent, for > example, varlena values good enough. Even if we have large int8 value > we can loose lower bits, b

Re: [HACKERS] Range Types - typo + NULL string constructor

Heikki Linnakangas writes: > * Have you tested this on an architecture with strict alignment? I don't > see any alignment bugs, but I think there's a lot of potential for them.. Well, fwiw, this patch passes its regression tests on HPPA, except for this which seems more to do with the already-no

Re: [HACKERS] Range Types - typo + NULL string constructor

Florian Pflug writes: > On Oct11, 2011, at 14:43 , David Fetter wrote: >> I'd recoil at not having ranges default to left-closed, right-open. >> The use case for that one is so compelling that I'm OK with making it >> the default from which deviations need to be specified. I agree with David on t

Re: [HACKERS] Range Types - typo + NULL string constructor

On Tue, Oct 11, 2011 at 12:18:18PM -0400, Robert Haas wrote: > On Tue, Oct 11, 2011 at 12:12 PM, David Fetter wrote: > > Nothing's bad about '[]' per se.  What's better, but possibly out > > of the reach of our current lexing and parsing system, would be > > things like: > > > > [1::int, 10) > >

Re: [HACKERS] Range Types - typo + NULL string constructor

Jeff Davis writes: > Tom made an observation about '[1,INT_MAX]' thowing an error because > canonicalization would try to increment INT_MAX. But I'm not > particularly disturbed by it. If you want a bigger range, use int8range > or numrange -- the same advice we give to people who want unsigned >

Re: [HACKERS] Range Types - typo + NULL string constructor

On Tue, 2011-10-11 at 12:40 -0400, Robert Haas wrote: > I think using '[)' is fine. At some level, this is just a question of > expectations. If you expect that int4range(1,4) will create a range > that includes 4, well, you're wrong. Once you get used to it, it will > seem normal, and you'll kn

Re: [HACKERS] Range Types - typo + NULL string constructor

On Tue, Oct 11, 2011 at 12:30 PM, Jeff Davis wrote: > On Tue, 2011-10-11 at 12:09 -0400, Robert Haas wrote: >> The cure seems worse than the disease.  What is so bad about '[]'? > > OK, so we stick with the 3-argument form. Do we have a default for the > third argument, or do we scrap it to avoid

Re: [HACKERS] Range Types - typo + NULL string constructor

On Tue, 2011-10-11 at 06:28 -0700, David Fetter wrote: > > Certainly not the end of the world, but is the convenience of being > > able to write somerange(a, b) instead of somerange(a, b, '[)') > > really worth it? I kind of doubt that... > > You're making a persuasive argument for the latter base

Re: [HACKERS] Range Types - typo + NULL string constructor

On Tue, 2011-10-11 at 12:09 -0400, Robert Haas wrote: > The cure seems worse than the disease. What is so bad about '[]'? OK, so we stick with the 3-argument form. Do we have a default for the third argument, or do we scrap it to avoid confusion? There were some fairly strong objections to using

Re: [HACKERS] Range Types - typo + NULL string constructor

On Tue, Oct 11, 2011 at 12:12 PM, David Fetter wrote: > Nothing's bad about '[]' per se.  What's better, but possibly out of > the reach of our current lexing and parsing system, would be things > like: > > [1::int, 10) That's been discussed before. Aside from the parser issues (which are formid

Re: [HACKERS] Range Types - typo + NULL string constructor

On Tue, Oct 11, 2011 at 12:09:01PM -0400, Robert Haas wrote: > On Tue, Oct 11, 2011 at 12:03 PM, Jeff Davis wrote: > > On Tue, 2011-10-11 at 06:28 -0700, David Fetter wrote: > >> > Certainly not the end of the world, but is the convenience of being > >> > able to write somerange(a, b) instead of s

Re: [HACKERS] Range Types - typo + NULL string constructor

On Tue, Oct 11, 2011 at 12:03 PM, Jeff Davis wrote: > On Tue, 2011-10-11 at 06:28 -0700, David Fetter wrote: >> > Certainly not the end of the world, but is the convenience of being >> > able to write somerange(a, b) instead of somerange(a, b, '[)') >> > really worth it? I kind of doubt that... >>

Re: [HACKERS] Range Types - typo + NULL string constructor

On Tue, Oct 11, 2011 at 03:20:05PM +0200, Florian Pflug wrote: > On Oct11, 2011, at 14:43 , David Fetter wrote: > > I'd recoil at not having ranges default to left-closed, > > right-open. The use case for that one is so compelling that I'm > > OK with making it the default from which deviations ne

Re: [HACKERS] Range Types - typo + NULL string constructor

On Oct11, 2011, at 14:43 , David Fetter wrote: > I'd recoil at not having ranges default to left-closed, right-open. > The use case for that one is so compelling that I'm OK with making it > the default from which deviations need to be specified. The downside of that is that, as Tom pointed out up

Re: [HACKERS] Range Types - typo + NULL string constructor

On Mon, Oct 10, 2011 at 10:25:18PM -0700, Jeff Davis wrote: > On Tue, 2011-10-11 at 03:14 +0200, Florian Pflug wrote: > > Maybe ranges over discrete types are slightly more likely to be > > closed, and ranges over continuous types slightly more likely to > > be open. Still, I very much doubt that t

Re: [HACKERS] Range Types - typo + NULL string constructor

On 11 October 2011 02:14, Florian Pflug wrote: > On Oct10, 2011, at 20:06 , Thom Brown wrote: >> Okay, a real example of why discrete should be '[]' and continuous >> should be '[)'. >> >> If you book a meeting from 09:00 to 11:00 (tsrange), at 11:00 >> precisely it either becomes free or is avail

Re: [HACKERS] Range Types - typo + NULL string constructor

On Tue, 2011-10-11 at 03:14 +0200, Florian Pflug wrote: > Maybe ranges over discrete types are slightly more likely to be closed, > and ranges over continuous types slightly more likely to be open. Still, > I very much doubt that the skew in the distribution is large enough to > warrant the confusi

Re: [HACKERS] Range Types - typo + NULL string constructor

On Oct10, 2011, at 19:41 , Jeff Davis wrote: > On Mon, 2011-10-10 at 19:22 +0200, Florian Pflug wrote: >> I still think we should strive for consistency here, so let's also make >> '[]' the default flags for the range constructors. > > For continuous ranges I don't think that's a good idea. Closed

Re: [HACKERS] Range Types - typo + NULL string constructor

On Oct10, 2011, at 20:06 , Thom Brown wrote: > Okay, a real example of why discrete should be '[]' and continuous > should be '[)'. > > If you book a meeting from 09:00 to 11:00 (tsrange), at 11:00 > precisely it either becomes free or is available to someone else, so > it can be booked 11:00 to 1

Re: [HACKERS] Range Types - typo + NULL string constructor

On 10 October 2011 18:53, Thom Brown wrote: > On 10 October 2011 18:45, Jeff Davis wrote: >> On Mon, 2011-10-10 at 18:39 +0100, Thom Brown wrote: >>>  So the default boundaries should be '[]' as opposed to '[)' as it is >>> now. >> >> Would that vary between range types? In other words, do I brin

Re: [HACKERS] Range Types - typo + NULL string constructor

On 10 October 2011 18:45, Jeff Davis wrote: > On Mon, 2011-10-10 at 18:39 +0100, Thom Brown wrote: >>  So the default boundaries should be '[]' as opposed to '[)' as it is >> now. > > Would that vary between range types? In other words, do I bring back > default_flags? > > If not, I think a lot of

Re: [HACKERS] Range Types - typo + NULL string constructor

On Mon, 2011-10-10 at 18:39 +0100, Thom Brown wrote: > So the default boundaries should be '[]' as opposed to '[)' as it is > now. Would that vary between range types? In other words, do I bring back default_flags? If not, I think a lot of people will object. The most common use-case for range t

Re: [HACKERS] Range Types - typo + NULL string constructor

On Mon, 2011-10-10 at 19:22 +0200, Florian Pflug wrote: > I still think we should strive for consistency here, so let's also make > '[]' the default flags for the range constructors. For continuous ranges I don't think that's a good idea. Closed-open is a very widely-accepted convention and there

Re: [HACKERS] Range Types - typo + NULL string constructor

On 10 October 2011 18:31, Jeff Davis wrote: > On Mon, 2011-10-10 at 12:53 -0400, Tom Lane wrote: >> > The "canonicalize" function (specified at type creation time) allows you >> > to specify the canonical output representation. So, I can change the >> > canonical form for discrete ranges to use '[

Re: [HACKERS] Range Types - typo + NULL string constructor

On Mon, 2011-10-10 at 12:53 -0400, Tom Lane wrote: > > The "canonicalize" function (specified at type creation time) allows you > > to specify the canonical output representation. So, I can change the > > canonical form for discrete ranges to use '[]' notation if we think > > that's more expected.

Re: [HACKERS] Range Types - typo + NULL string constructor

On Oct10, 2011, at 18:53 , Tom Lane wrote: > What if I write '[1,INT_MAX]'::int4range? The open-parenthesis form will > fail with an integer overflow. I suppose you could canonicalize it to > an unbounded range, but that seems unnecessarily surprising. That is a very good point. Canonicalizing t

Re: [HACKERS] Range Types - typo + NULL string constructor

Jeff Davis writes: > On Mon, 2011-10-10 at 14:27 +0100, Thom Brown wrote: >> I don't know if this has already been discussed, but can you explain >> the following: >> >> postgres=# select '[1,8]'::int4range; >> int4range >> --- >> [1,9) >> (1 row) >> >> It seems unintuitive to represent

Re: [HACKERS] Range Types - typo + NULL string constructor

On Mon, 2011-10-10 at 14:27 +0100, Thom Brown wrote: > I don't know if this has already been discussed, but can you explain > the following: > > postgres=# select '[1,8]'::int4range; > int4range > --- > [1,9) > (1 row) > > It seems unintuitive to represent a discrete range using an excl

Re: [HACKERS] Range Types - typo + NULL string constructor

On 2 October 2011 20:05, Jeff Davis wrote: > On Sun, 2011-10-02 at 11:32 +0200, Florian Pflug wrote: >> Looking at the patch, I noticed that it's possible to specify the default >> boundaries ([], [), (] or ()) per individual float type with the >> DEFAULT_FLAGS clause of CREATE TYPE .. AS RANGE.

Re: [HACKERS] Range Types - typo + NULL string constructor

Jeff Davis writes: > On Sat, 2011-10-08 at 12:44 -0700, Jeff Janes wrote: >> When I apply this to head, "make check" fails with: >> >> create type textrange_en_us as range(subtype=text, collation="en_US"); >> + ERROR: collation "en_US" for encoding "SQL_ASCII" does not exist > Thank you for poi

Re: [HACKERS] Range Types - typo + NULL string constructor

On Sat, 2011-10-08 at 12:44 -0700, Jeff Janes wrote: > When I apply this to head, "make check" fails with: > > create type textrange_en_us as range(subtype=text, collation="en_US"); > + ERROR: collation "en_US" for encoding "SQL_ASCII" does not exist > > Is this a problem? e.g. will it break

Re: [HACKERS] Range Types - typo + NULL string constructor

On Sun, Oct 2, 2011 at 12:05 PM, Jeff Davis wrote: > On Sun, 2011-10-02 at 11:32 +0200, Florian Pflug wrote: >> Looking at the patch, I noticed that it's possible to specify the default >> boundaries ([], [), (] or ()) per individual float type with the >> DEFAULT_FLAGS clause of CREATE TYPE .. AS

Re: GiST for range types (was Re: [HACKERS] Range Types - typo + NULL string constructor)

On Sat, 2011-10-08 at 18:43 +0400, Alexander Korotkov wrote: > I meant that penalty can be determined as sum of difference of old and > new bounds of range, i.e. penalty = subtype_diff_float(new_lower, > old_lower) + subtype_diff_float(old_upper, new_upper). > When we insert [100,200) into [10,+i

Re: GiST for range types (was Re: [HACKERS] Range Types - typo + NULL string constructor)

On Sat, Oct 8, 2011 at 1:01 PM, Jeff Davis wrote: > On Fri, 2011-10-07 at 12:54 +0400, Alexander Korotkov wrote: > > > The first thing caught my eye in existing GiST code is idea of > > subtype_float. float8 has limited precision and can't respresent, for > > example, varlena values good enough.

Re: GiST for range types (was Re: [HACKERS] Range Types - typo + NULL string constructor)

On Fri, 2011-10-07 at 12:54 +0400, Alexander Korotkov wrote: > The first thing caught my eye in existing GiST code is idea of > subtype_float. float8 has limited precision and can't respresent, for > example, varlena values good enough. Even if we have large int8 value > we can loose lower bits, b

GiST for range types (was Re: [HACKERS] Range Types - typo + NULL string constructor)

On Fri, Oct 7, 2011 at 7:41 AM, Jeff Davis wrote: > I'd prefer to include it in the initial patch. If the current GiST code > is going to be replaced, then there's not much sense reviewing/testing > it. > > You may need to consider unbounded and empty ranges specially. I made an > attempt to do s

Re: [HACKERS] Range Types - typo + NULL string constructor

On Thu, 2011-10-06 at 23:26 +0400, Alexander Korotkov wrote: > Hi, Jeff! > > > Heikki has recently commited my patch about picksplit for GiST on > points and boxes: > http://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=7f3bd86843e5aad84585a57d3f6b80db3c609916 > I would like to try t

Re: [HACKERS] Range Types - typo + NULL string constructor

Hi, Jeff! Heikki has recently commited my patch about picksplit for GiST on points and boxes: http://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=7f3bd86843e5aad84585a57d3f6b80db3c609916 I would like to try this picksplit method on ranges. I believe that it might be much more efficie

Re: [HACKERS] Range Types - typo + NULL string constructor

On Sun, 2011-10-02 at 11:32 +0200, Florian Pflug wrote: > Looking at the patch, I noticed that it's possible to specify the default > boundaries ([], [), (] or ()) per individual float type with the > DEFAULT_FLAGS clause of CREATE TYPE .. AS RANGE. I wonder if that doesn't > do more harm then good

Re: [HACKERS] Range Types - typo + NULL string constructor

On Oct2, 2011, at 08:12 , Jeff Davis wrote: > Done. Now range types more closely resemble records in parsing behavior. > Patch attached. Cool! Looking at the patch, I noticed that it's possible to specify the default boundaries ([], [), (] or ()) per individual float type with the DEFAULT_FLAGS c

Re: [HACKERS] Range Types - typo + NULL string constructor

On Thu, 2011-09-22 at 02:31 +0200, Florian Pflug wrote: > My personal favourite would be '0', since it resembles the symbol used > for empty sets in mathematics, and we already decided to use mathematical > notation for ranges. > > If we're concerned that most of our users won't get that, then 'em

Re: [HACKERS] Range Types - typo + NULL string constructor

On Sep21, 2011, at 19:02 , Jeff Davis wrote: > On Wed, 2011-09-21 at 13:24 +0200, Florian Pflug wrote: >> I've thought about this some more, and came to realize that the question >> here really is whether >> >> floatrange(0, 'Infinity'::float, '[)') >> >> and >> >> floatrange(0, NULL, '[)') >>

Re: [HACKERS] Range Types - typo + NULL string constructor

On Sep21, 2011, at 19:00 , Jeff Davis wrote: > While we're at it, any suggestions on the text representation of an > empty range? My personal favourite would be '0', since it resembles the symbol used for empty sets in mathematics, and we already decided to use mathematical notation for ranges. I

Re: [HACKERS] Range Types - typo + NULL string constructor

On Wed, 2011-09-21 at 13:24 +0200, Florian Pflug wrote: > I've thought about this some more, and came to realize that the question > here really is whether > > floatrange(0, 'Infinity'::float, '[)') > > and > > floatrange(0, NULL, '[)') > > are the same thing or not. The unbounded side of

Re: [HACKERS] Range Types - typo + NULL string constructor

On Wed, 2011-09-21 at 17:20 +0200, Florian Pflug wrote: > Hm, so we'd have > > '(X,)' for range(X, NULL, '()'), > '(,X)' for range(NULL, X, '()') and > '(,)' for range(NULL, NULL, '()'). > > We'd then have the choice of either declaring > > '(X,]' to mean '(X,)', > '[,X)' to mean '(,X)

Re: [HACKERS] Range Types - typo + NULL string constructor

On Sep21, 2011, at 16:41 , Tom Lane wrote: > Florian Pflug writes: >> On Sep21, 2011, at 14:00 , Robert Haas wrote: >>> Otherwise, anyone >>> who wants to construct these strings programatically is going to need >>> to escape everything and always write ("cat","dog") or however you do >>> that, an

Re: [HACKERS] Range Types - typo + NULL string constructor

Florian Pflug writes: > On Sep21, 2011, at 14:00 , Robert Haas wrote: >> Otherwise, anyone >> who wants to construct these strings programatically is going to need >> to escape everything and always write ("cat","dog") or however you do >> that, and that seems like an unnecessary imposition. > Un

Re: [HACKERS] Range Types - typo + NULL string constructor

On Wed, Sep 21, 2011 at 8:41 AM, Florian Pflug wrote: >> Boy, that seems really weird to me.  If you're going to do it, it >> ought to be case-insensitive, but I think detecting the case only for >> the purpose of rejecting it is probably a mistake.  I mean, if >> (nubile, nutty) is OK, then (nubi

Re: [HACKERS] Range Types - typo + NULL string constructor

On Sep21, 2011, at 14:00 , Robert Haas wrote: > On Wed, Sep 21, 2011 at 3:29 AM, Jeff Davis wrote: >> On Mon, 2011-09-19 at 12:26 -0400, Robert Haas wrote: >>> (I am also vaguely wondering what happens if if you have a text >>> range is (nubile, null) ambiguous?) >> >> There are a few ways to

Re: [HACKERS] Range Types - typo + NULL string constructor

On Wed, Sep 21, 2011 at 3:29 AM, Jeff Davis wrote: > On Mon, 2011-09-19 at 12:26 -0400, Robert Haas wrote: >> What I really >> care about is that we don't talk ourselves into needing a zillion >> constructor functions.  Making things work with a single constructor >> function seems to me to simpli

Re: [HACKERS] Range Types - typo + NULL string constructor

On Sep21, 2011, at 09:23 , Jeff Davis wrote: > On Mon, 2011-09-19 at 18:32 +0200, Florian Pflug wrote: >> No, but more similar the format are the easier it gets to at least factor >> the hairy parts of such a parser into a common subroutine. Assume that we >> don't support NULL as an alias for INF.

  1   2   >