Alexander Korotkov aekorot...@gmail.com writes:
On Mon, Jan 30, 2012 at 1:39 AM, Jeff Davis pg...@j-davis.com 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
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
On Mon, Jan 30, 2012 at 1:39 AM, Jeff Davis pg...@j-davis.com 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
Hi!
New version of patch is attached.
On Thu, Dec 22, 2011 at 11:46 AM, Jeff Davis pg...@j-davis.com 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
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
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. Mapping
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
On 12/13/2011 04:04 PM, Alexander Korotkov wrote:
On Mon, Dec 12, 2011 at 10:41 PM, Jeff Davis pg...@j-davis.com
mailto:pg...@j-davis.com 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
Hi!
On Mon, Dec 12, 2011 at 10:41 PM, Jeff Davis pg...@j-davis.com 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
On Sat, Dec 10, 2011 at 6:14 PM, Greg Smith g...@2ndquadrant.com 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
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
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
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
On Sat, Nov 26, 2011 at 11:11 AM, Jeff Davis pg...@j-davis.com 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
Alexander Korotkov aekorot...@gmail.com writes:
On Sat, Nov 26, 2011 at 11:11 AM, Jeff Davis pg...@j-davis.com 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
On Sun, Nov 27, 2011 at 10:43 PM, Tom Lane t...@sss.pgh.pa.us 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
Alexander Korotkov aekorot...@gmail.com writes:
On Sun, Nov 27, 2011 at 10:43 PM, Tom Lane t...@sss.pgh.pa.us 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
On Mon, Nov 28, 2011 at 3:00 AM, Tom Lane t...@sss.pgh.pa.us 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
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,
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
Alexander Korotkov aekorot...@gmail.com 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
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
On 07.11.2011 20:36, Tom Lane wrote:
Alexander Korotkovaekorot...@gmail.com 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.
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 those
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):
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 range
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
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
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!
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 well
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 as a
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
Heikki Linnakangas heikki.linnakan...@enterprisedb.com 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
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
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
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
On Tue, Oct 25, 2011 at 12:37 PM, Jeff Davis pg...@j-davis.com 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.
On 26.10.2011 18:42, Robert Haas wrote:
On Tue, Oct 25, 2011 at 12:37 PM, Jeff Davispg...@j-davis.com 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
On Wed, Oct 26, 2011 at 11:52 AM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
On 26.10.2011 18:42, Robert Haas wrote:
On Tue, Oct 25, 2011 at 12:37 PM, Jeff Davispg...@j-davis.com wrote:
Aren't there a few other cases like this floating around the code? I
know the
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
heikki.linnakan...@enterprisedb.com wrote:
1. In session A: BEGIN; SELECT * FROM foo WHERE id = 1; COMMIT;
The row has xmin = 123456, and it is cached as committed
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-around
Heikki Linnakangas heikki.linnakan...@enterprisedb.com 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,
Robert Haas robertmh...@gmail.com 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
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
On Mon, Oct 24, 2011 at 3:05 PM, Alexander Korotkov aekorot...@gmail.comwrote:
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
Hi!
On Mon, Oct 17, 2011 at 12:38 PM, Jeff Davis pg...@j-davis.com 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
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
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. Even
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, but
Heikki Linnakangas heikki.linnakan...@enterprisedb.com 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
On 11 October 2011 02:14, Florian Pflug f...@phlo.org 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
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 the
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
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 need to
On Tue, Oct 11, 2011 at 12:03 PM, Jeff Davis pg...@j-davis.com 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
On Tue, Oct 11, 2011 at 12:09:01PM -0400, Robert Haas wrote:
On Tue, Oct 11, 2011 at 12:03 PM, Jeff Davis pg...@j-davis.com 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)
On Tue, Oct 11, 2011 at 12:12 PM, David Fetter da...@fetter.org 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
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
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 based
On Tue, Oct 11, 2011 at 12:30 PM, Jeff Davis pg...@j-davis.com 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
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 know
Jeff Davis pg...@j-davis.com 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
On Tue, Oct 11, 2011 at 12:18:18PM -0400, Robert Haas wrote:
On Tue, Oct 11, 2011 at 12:12 PM, David Fetter da...@fetter.org 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)
Florian Pflug f...@phlo.org 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
On 2 October 2011 20:05, Jeff Davis pg...@j-davis.com 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 ..
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 exclusive
Jeff Davis pg...@j-davis.com 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 a
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 to
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.
What
On 10 October 2011 18:31, Jeff Davis pg...@j-davis.com 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
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
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
On 10 October 2011 18:45, Jeff Davis pg...@j-davis.com 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
On 10 October 2011 18:53, Thom Brown t...@linux.com wrote:
On 10 October 2011 18:45, Jeff Davis pg...@j-davis.com 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
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 12:00
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-open
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 confusion
Jeff Davis pg...@j-davis.com 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
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, but
On Sat, Oct 8, 2011 at 1:01 PM, Jeff Davis pg...@j-davis.com 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
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
On Sun, Oct 2, 2011 at 12:05 PM, Jeff Davis pg...@j-davis.com 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
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 the
On Fri, Oct 7, 2011 at 7:41 AM, Jeff Davis pg...@j-davis.com 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
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
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 this
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
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 -
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 'empty'
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. What would then be the result of
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 simplify life quite a bit, and allowing there
seems essential for
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. What
On Wed, Sep 21, 2011 at 3:29 AM, Jeff Davis pg...@j-davis.com 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
On Sep21, 2011, at 14:00 , Robert Haas wrote:
On Wed, Sep 21, 2011 at 3:29 AM, Jeff Davis pg...@j-davis.com 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
On Wed, Sep 21, 2011 at 8:41 AM, Florian Pflug f...@phlo.org 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
Florian Pflug f...@phlo.org 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.
On Sep21, 2011, at 16:41 , Tom Lane wrote:
Florian Pflug f...@phlo.org 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
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)' and
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 a range
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.
If
1 - 100 of 110 matches
Mail list logo
