2010/10/26 Robert Haas robertmh...@gmail.com:
On Mon, Oct 25, 2010 at 8:13 PM, Jeff Davis pg...@j-davis.com wrote:
On Mon, 2010-10-25 at 18:03 -0400, Robert Haas wrote:
Hmm. Do you have some concrete examples of cases where a range type
might want to do some representational optimization?
On Mon, 2010-10-25 at 21:07 -0400, Robert Haas wrote:
See, that gets complicated, because now you're restricting the range
of values that can be expressed by the range type to something less
than the natural range of the data type. I am not sure the value of
supporting that is sufficient to
On Tue, Oct 26, 2010 at 1:26 PM, Jeff Davis pg...@j-davis.com wrote:
On Mon, 2010-10-25 at 21:07 -0400, Robert Haas wrote:
See, that gets complicated, because now you're restricting the range
of values that can be expressed by the range type to something less
than the natural range of the data
Robert Haas robertmh...@gmail.com writes:
On Tue, Oct 26, 2010 at 1:26 PM, Jeff Davis pg...@j-davis.com wrote:
However, this is orthogonal, I think. I can always ask the user to
specify everything when creating a Range Type, and then we can make them
default to use the interface functions
On Tue, Oct 26, 2010 at 1:42 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Tue, Oct 26, 2010 at 1:26 PM, Jeff Davis pg...@j-davis.com wrote:
However, this is orthogonal, I think. I can always ask the user to
specify everything when creating a Range Type,
On Sun, Oct 24, 2010 at 06:59:34PM -0400, Tom Lane wrote:
Jeff Davis pg...@j-davis.com writes:
Last development cycle, one of the questions that was unresolved
was whether to handle ranges like a discrete set (that is, [1,5) =
[1,4] ) or continuous or both.
Put me in the camp that says
On 25.10.2010 01:59, Tom Lane wrote:
Jeff Davispg...@j-davis.com writes:
If we treat those as discrete, then R1 = R2, R1 contains R2, R2 contains
R1, and R2 - R1 = R1 - R2 = empty. However, if we treat those as
continuous, then we get a contradiction:
R2 contains R1
R1 does not contain R2
David Fetter da...@fetter.org writes:
On Sun, Oct 24, 2010 at 06:59:34PM -0400, Tom Lane wrote:
Put me in the camp that says you need both. I really seriously
dislike the idea of representing [1, 2) as [1, 2-epsilon], mainly
because there is often no portable value for epsilon.
On Mon, Oct 25, 2010 at 10:21:49AM -0400, Tom Lane wrote:
David Fetter da...@fetter.org writes:
On Sun, Oct 24, 2010 at 06:59:34PM -0400, Tom Lane wrote:
Put me in the camp that says you need both. I really seriously
dislike the idea of representing [1, 2) as [1, 2-epsilon], mainly
On Sun, 2010-10-24 at 18:59 -0400, Tom Lane wrote:
Jeff Davis pg...@j-davis.com writes:
Last development cycle, one of the questions that was unresolved was
whether to handle ranges like a discrete set (that is, [1,5) = [1,4] )
or continuous or both.
Put me in the camp that says you need
On Mon, Oct 25, 2010 at 12:51 PM, Jeff Davis pg...@j-davis.com wrote:
On Sun, 2010-10-24 at 18:59 -0400, Tom Lane wrote:
Jeff Davis pg...@j-davis.com writes:
Last development cycle, one of the questions that was unresolved was
whether to handle ranges like a discrete set (that is, [1,5) =
Jeff Davis pg...@j-davis.com wrote:
Last development cycle, one of the questions that was unresolved
was whether to handle ranges like a discrete set (that is, [1,5) =
[1,4] ) or continuous or both.
I think that discrete ranges are required. For instance, day range
and IP address ranges
On Mon, 2010-10-25 at 12:20 -0500, Kevin Grittner wrote:
It would be very useful to be able to specify a granularity -- for
example timestamps with a five minute granularity would be useful
for scheduling appointments. In some cases the granularity might be
inferred -- if we have a domain
On Mon, Oct 25, 2010 at 2:01 PM, Jeff Davis pg...@j-davis.com wrote:
On Mon, 2010-10-25 at 12:20 -0500, Kevin Grittner wrote:
It would be very useful to be able to specify a granularity -- for
example timestamps with a five minute granularity would be useful
for scheduling appointments. In
On Mon, 2010-10-25 at 13:00 -0400, Robert Haas wrote:
I'm still confused. It seems to me (and maybe I'm full of it) that
the distinction between continuous ranges and discrete ranges is
pretty minor. Suppose you have continuous ranges done, and working.
The only thing you need to add for
On Mon, 2010-10-25 at 14:11 -0400, Robert Haas wrote:
On Mon, Oct 25, 2010 at 2:01 PM, Jeff Davis pg...@j-davis.com wrote:
On Mon, 2010-10-25 at 12:20 -0500, Kevin Grittner wrote:
It would be very useful to be able to specify a granularity -- for
example timestamps with a five minute
On Mon, Oct 25, 2010 at 2:27 PM, Jeff Davis pg...@j-davis.com wrote:
On Mon, 2010-10-25 at 13:00 -0400, Robert Haas wrote:
I'm still confused. It seems to me (and maybe I'm full of it) that
the distinction between continuous ranges and discrete ranges is
pretty minor. Suppose you have
On Mon, Oct 25, 2010 at 2:44 PM, Jeff Davis pg...@j-davis.com wrote:
On Mon, 2010-10-25 at 14:11 -0400, Robert Haas wrote:
On Mon, Oct 25, 2010 at 2:01 PM, Jeff Davis pg...@j-davis.com wrote:
On Mon, 2010-10-25 at 12:20 -0500, Kevin Grittner wrote:
It would be very useful to be able to
On Mon, 2010-10-25 at 18:28 -0400, Robert Haas wrote:
Oh, maybe I'm confused. Are you saying you'd need multiple copies of
the base type, or multiple range types based on a single base type?
The latter. That is, if you want a timestamp range with granularity 1
second, and a timestamp range
On Mon, 2010-10-25 at 18:03 -0400, Robert Haas wrote:
Hmm. Do you have some concrete examples of cases where a range type
might want to do some representational optimization?
Let's say for instance you want to keep an timestamp range in 16 bytes.
You could have an 8-byte timestamp, a 7-byte
On Mon, Oct 25, 2010 at 8:01 PM, Jeff Davis pg...@j-davis.com wrote:
On Mon, 2010-10-25 at 18:28 -0400, Robert Haas wrote:
Oh, maybe I'm confused. Are you saying you'd need multiple copies of
the base type, or multiple range types based on a single base type?
The latter. That is, if you want
On Mon, Oct 25, 2010 at 8:13 PM, Jeff Davis pg...@j-davis.com wrote:
On Mon, 2010-10-25 at 18:03 -0400, Robert Haas wrote:
Hmm. Do you have some concrete examples of cases where a range type
might want to do some representational optimization?
Let's say for instance you want to keep an
Jeff Davis pg...@j-davis.com writes:
Last development cycle, one of the questions that was unresolved was
whether to handle ranges like a discrete set (that is, [1,5) = [1,4] )
or continuous or both.
Put me in the camp that says you need both. I really seriously dislike
the idea of
On Sun, Oct 24, 2010 at 6:59 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Jeff Davis pg...@j-davis.com writes:
Last development cycle, one of the questions that was unresolved was
whether to handle ranges like a discrete set (that is, [1,5) = [1,4] )
or continuous or both.
Put me in the camp that
On Dec 15, 2009, at 6:29 PM, Jeff Davis wrote:
On Tue, 2009-12-15 at 18:06 -0600, decibel wrote:
Now that varlena's don't have an enormous fixed overhead, perhaps it's
worth looking at using them. Obviously some operations would be
slower, but for your stated examples of auditing and history,
Tom Lane t...@sss.pgh.pa.us writes:
Dimitri Fontaine dfonta...@hi-media.com writes:
Tom Lane t...@sss.pgh.pa.us writes:
foreach p2_member in unnest(p2) loop
p1 := array(select period_except(p1_member, p2_member)
from unnest(p1) p1_member);
end
Dimitri Fontaine dfonta...@hi-media.com writes:
Tom Lane t...@sss.pgh.pa.us writes:
Hm, how would you do it with LATERAL? The problem is not so much
composition as the need for a variable number of rounds of
composition.
Let's have a try at it:
select p2_member, array_accum(p1)
from
Tom == Tom Lane t...@sss.pgh.pa.us writes:
Someone mentioned LATERAL?
Tom Lane t...@sss.pgh.pa.us writes:
Hm, how would you do it with LATERAL? The problem is not so much
composition as the need for a variable number of rounds of
composition.
Let's have a try at it:
select
Tom Lane wrote:
Dimitri Fontaine dfonta...@hi-media.com writes:
Tom Lane t...@sss.pgh.pa.us writes:
Hm, how would you do it with LATERAL? The problem is not so much
composition as the need for a variable number of rounds of
composition.
Let's have a try at it:
select p2_member,
Tom Lane t...@sss.pgh.pa.us writes:
foreach p2_member in unnest(p2) loop
p1 := array(select period_except(p1_member, p2_member)
from unnest(p1) p1_member);
end loop;
But maybe it can be done in a single SQL command.
Yeah, as soon as you have LATERAL,
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Tue, Dec 15, 2009 at 04:16:28PM +0100, Nicolas Barbier wrote:
[...]
whatever
and
same whatever as before + the character with the lowest value in
lexicographical ordering.
I don't think it is possible to get anything in between those
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Tue, Dec 15, 2009 at 11:49:19AM -0800, David Fetter wrote:
On Tue, Dec 15, 2009 at 11:31:05AM -0800, Scott Bailey wrote:
Jeff Davis wrote:
On Tue, 2009-12-15 at 10:19 -0500, Tom Lane wrote:
Would it be OK if we handled float timestamp
Dimitri Fontaine dfonta...@hi-media.com writes:
Tom Lane t...@sss.pgh.pa.us writes:
foreach p2_member in unnest(p2) loop
p1 := array(select period_except(p1_member, p2_member)
from unnest(p1) p1_member);
end loop;
But maybe it can be done in
On Sun, 2009-12-13 at 23:49 -0800, Scott Bailey wrote:
So basically I have an anyrange pseudo type with the functions prev,
next, last, etc defined. So instead of hard coding range types, we would
allow the user to define their own range types. Basically if we are able
to determine the
On Wed, Dec 16, 2009 at 12:31 PM, Jeff Davis pg...@j-davis.com wrote:
There's one problem, and that's for timestamptz ranges with intervals
that include days and months. Timezone adjustments are just not
well-defined for that kind of granule (nor would it be particularly
useful even if it
Jeff Davis pg...@j-davis.com writes:
[ hacky special-case representation for discrete timestamp ranges ]
I'm still not exactly clear on what the use-case is for discrete
timestamp ranges, and I wonder how many people are going to be happy
with a representation that can't handle a range that's
Jeff Davis wrote:
On Sun, 2009-12-13 at 23:49 -0800, Scott Bailey wrote:
So basically I have an anyrange pseudo type with the functions prev,
next, last, etc defined. So instead of hard coding range types, we would
allow the user to define their own range types. Basically if we are able
to
Tom Lane wrote:
Jeff Davis pg...@j-davis.com writes:
[ hacky special-case representation for discrete timestamp ranges ]
I'm still not exactly clear on what the use-case is for discrete
timestamp ranges, and I wonder how many people are going to be happy
with a representation that can't
Ok, silly question here. But how do you determine the length of a
continuous range? By definition length of [a, b) and (a, b] = b-a. But
what about (a,b) and [a,b]? Are we saying that because they are
continuous, the difference between values included in the range and
those excluded are so
Scott Bailey arta...@comcast.net writes:
As I pointed out off-list, I think the granularity for timestamp range
should be limited to hours and smaller. Anything larger is asking for
trouble. And quite honestly if they wanted day granularity, they should
use date range.
I'm still not real
On Wed, 2009-12-16 at 12:42 -0500, Robert Haas wrote:
On Wed, Dec 16, 2009 at 12:31 PM, Jeff Davis pg...@j-davis.com wrote:
There's one problem, and that's for timestamptz ranges with intervals
that include days and months. Timezone adjustments are just not
well-defined for that kind of
On Wed, 2009-12-16 at 12:50 -0500, Tom Lane wrote:
I'm still not exactly clear on what the use-case is for discrete
timestamp ranges, and I wonder how many people are going to be happy
with a representation that can't handle a range that's open-ended
on the left.
Huh? We're miscommunicating
to...@tuxteam.de wrote:
(and as Andrew Dunstan pointed out off-list: I was wrong with my bold
assertion that one can squeeze infinitely many (arbitrary length)
strings between two given. This is not always the case).
Of course you can do that if you assume lexicographical order, or any
other
On Tue, Dec 15, 2009 at 04:29:26PM -0800, Jeff Davis wrote:
On Tue, 2009-12-15 at 18:06 -0600, decibel wrote:
Now that varlena's don't have an enormous fixed overhead, perhaps it's
worth looking at using them. Obviously some operations would be
slower, but for your stated examples of
On Wed, Dec 16, 2009 at 10:57:19AM -0800, Scott Bailey wrote:
Ok, silly question here. But how do you determine the length of a
continuous range? By definition length of [a, b) and (a, b] = b-a. But
what about (a,b) and [a,b]? Are we saying that because they are
continuous, the
Alvaro Herrera alvhe...@commandprompt.com writes:
In short, I think that while it is possible to define ranges of strings,
it is not as useful as one would like.
Note it is not the *range* that is the problem, it is the assumption
that there's a unique next string. There's no unique next in
On Wed, 2009-12-16 at 13:59 -0500, Tom Lane wrote:
The argument for having
granularity wired into the datatype seems to boil down to just space
savings. I don't find that compelling enough to justify code
contortions and user-visible restrictions on functionality.
The argument (at least from
Tom Lane wrote:
Alvaro Herrera alvhe...@commandprompt.com writes:
In short, I think that while it is possible to define ranges of strings,
it is not as useful as one would like.
Note it is not the *range* that is the problem, it is the assumption
that there's a unique next string.
Martijn van Oosterhout klep...@svana.org writes:
But a period type will take just one or two more bytes if you don't
require alignment. Alignment on a varlena type seems silly anyway,
since you'll be aligning the header byte rather than the content.
You might still end up paying the alignment
Jeff Davis pg...@j-davis.com writes:
On Wed, 2009-12-16 at 12:50 -0500, Tom Lane wrote:
I'm still not exactly clear on what the use-case is for discrete
timestamp ranges, and I wonder how many people are going to be happy
with a representation that can't handle a range that's open-ended
on
Jeff Davis pg...@j-davis.com writes:
On Wed, 2009-12-16 at 13:59 -0500, Tom Lane wrote:
The argument for having
granularity wired into the datatype seems to boil down to just space
savings. I don't find that compelling enough to justify code
contortions and user-visible restrictions on
On Wed, Dec 16, 2009 at 03:57:44PM -0500, Tom Lane wrote:
Jeff Davis pg...@j-davis.com writes:
I still have not seen an answer to the problem of changing the
representation of a continuous range. If you have the continuous range
[5, 10], you're pretty much stuck with that representation,
On Wed, 2009-12-16 at 15:46 -0500, Tom Lane wrote:
Huh? We're miscommunicating somewhere.
Yeah, apparently. By open-ended I meant -infinity left bound, or null
left bound if you prefer. Not sure if there's a better term.
But my proposal allowed both of those things with various flag
Martijn van Oosterhout klep...@svana.org writes:
However, it does seem reasonable to allow people to restrict, either by
typmod or a check constraint the kinds of values that can be stored in
a particular column. Then an application can decide which way they want
their intervals to work and
On Wed, 2009-12-16 at 15:57 -0500, Tom Lane wrote:
Making it explicit doesn't fix the fact that you can't rely on the
arithmetic to be exact.
Can't rely on what arithmetic to be exact? Int64 timestamps should
clearly work for granules of 1 second.
If the administrator can choose a timestamp
Tom Lane wrote:
Martijn van Oosterhout klep...@svana.org writes:
However, it does seem reasonable to allow people to restrict, either by
typmod or a check constraint the kinds of values that can be stored in
a particular column. Then an application can decide which way they want
their intervals
On Wed, 2009-12-16 at 13:59 -0500, Tom Lane wrote:
For example, if you're trying to do classroom scheduling, it might be
useful to constrain the periods to start and end on hour boundaries
--- but the next thing you'll want is to have it know that the next
slot after 5pm Friday is 8am Monday.
On Wed, 2009-12-16 at 14:29 +0100, to...@tuxteam.de wrote:
This alone would practically preclude discrete -- int and float would
behave quite differently (float's granules growing towards the edges
or having to choose a bigger granule for float than for int in the first
place).
It may be an
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Wed, Dec 16, 2009 at 04:45:54PM -0300, Alvaro Herrera wrote:
to...@tuxteam.de wrote:
(and as Andrew Dunstan pointed out off-list: I was wrong with my bold
assertion that one can squeeze infinitely many (arbitrary length)
strings between
On Tue, Dec 15, 2009 at 7:28 AM, to...@tuxteam.de wrote:
The situation is even more restricted with floats (they are much
smaller; thus one could say that they're more discrete than strings,
even). Problem with floats is -- the granule is not the same size over
the whole range (nasty), and
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Tue, Dec 15, 2009 at 01:09:02PM +, Greg Stark wrote:
[...]
In fact, as I only recently found out, one of the design goals of IEEE
floats was specifically that they sort lexicographically and use every
bit pattern. So you can alwys get the
to...@tuxteam.de writes:
(and as Andrew Dunstan pointed out off-list: I was wrong with my bold
assertion that one can squeeze infinitely many (arbitrary length)
strings between two given. This is not always the case).
Really? If the string length is unbounded I think you were right.
Greg Stark gsst...@mit.edu writes:
In fact, as I only recently found out, one of the design goals of IEEE
floats was specifically that they sort lexicographically and use every
bit pattern. So you can alwys get the next float by just
incrementing your float as an 64-bit integer. Yes that
On Tue, Dec 15, 2009 at 9:58 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Greg Stark gsst...@mit.edu writes:
In fact, as I only recently found out, one of the design goals of IEEE
floats was specifically that they sort lexicographically and use every
bit pattern. So you can alwys get the next float
2009/12/15 Tom Lane t...@sss.pgh.pa.us:
to...@tuxteam.de writes:
(and as Andrew Dunstan pointed out off-list: I was wrong with my bold
assertion that one can squeeze infinitely many (arbitrary length)
strings between two given. This is not always the case).
Really? If the string length is
Robert Haas robertmh...@gmail.com writes:
I also have to say that I'm very skeptical of the argument
that there is only a small list of types people will want this for.
I'm not sure that anyone has argued that. I did suggest that there
might be a small list of types for which we should provide
On Tue, Dec 15, 2009 at 10:19 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
I also have to say that I'm very skeptical of the argument
that there is only a small list of types people will want this for.
I'm not sure that anyone has argued that. I did
Nicolas Barbier nicolas.barb...@gmail.com writes:
Assuming lexicographical ordering (first different character
determines order; end-of-string is sorted before anything else),
consider the following two strings:
whatever
and
same whatever as before + the character with the lowest value in
On 15.12.09 15:52 , Tom Lane wrote:
to...@tuxteam.de writes:
(and as Andrew Dunstan pointed out off-list: I was wrong with my
bold assertion that one can squeeze infinitely many (arbitrary
length) strings between two given. This is not always the case).
Really? If the string length is
Tom Lane wrote:
So the long and the short of it is that next/previous are not
going to work for string types, maxlength or no maxlength.
Even more importantly, I strongly doubt they would be of the slightest
practical value.
cheers
andrew
--
Sent via
On Tue, 2009-12-15 at 10:19 -0500, Tom Lane wrote:
I'm not sure that anyone has argued that. I did suggest that there
might be a small list of types for which we should provide discrete
behavior (ie, with next/previous functions) and the rest could have
continuous behavior (without that
Jeff Davis pg...@j-davis.com writes:
If I'm correct, continuous ranges always need two extra bits of storage
for the exclusivity. But for timestamps, that means 16 bytes (2 x 8-byte
timestamp) turns into 17 bytes, which is really more like 20 or 24 bytes
with alignment.
You probably need some
Jeff Davis wrote:
On Tue, 2009-12-15 at 10:19 -0500, Tom Lane wrote:
I'm not sure that anyone has argued that. I did suggest that there
might be a small list of types for which we should provide discrete
behavior (ie, with next/previous functions) and the rest could have
continuous behavior
On Tue, Dec 15, 2009 at 11:31:05AM -0800, Scott Bailey wrote:
Jeff Davis wrote:
On Tue, 2009-12-15 at 10:19 -0500, Tom Lane wrote:
Would it be OK if we handled float timestamp ranges as continuous
and int64 timestamps discrete?
That sounds like a recipe for disaster. Whatever timestamp
David Fetter da...@fetter.org writes:
On Tue, Dec 15, 2009 at 11:31:05AM -0800, Scott Bailey wrote:
As for the extra bits, would it be better to just require continuous
ranges to be either [] or [)? But I don't know which would be
preferred. My inclination would be toward [), but Tom seemed to
On Tue, 2009-12-15 at 13:15 -0500, Tom Lane wrote:
You probably need some flag bits anyway, so flailing frantically to
avoid that doesn't seem like a profitable use of time.
I think need and flailing are both a little too strong here. The
biggest use case will almost certainly be ranges of
Jeff Davis pg...@j-davis.com writes:
I think need and flailing are both a little too strong here. The
biggest use case will almost certainly be ranges of timestamps, and most
of those people will have no use for flag bits (or if they do, it might
not be worth an 8-byte-per-value overhead).
David Fetter wrote:
On Tue, Dec 15, 2009 at 11:31:05AM -0800, Scott Bailey wrote:
Jeff Davis wrote:
On Tue, 2009-12-15 at 10:19 -0500, Tom Lane wrote:
Would it be OK if we handled float timestamp ranges as continuous
and int64 timestamps discrete?
That sounds like a recipe for disaster.
On Tue, 2009-12-15 at 11:49 -0800, David Fetter wrote:
That sounds like a recipe for disaster. Whatever timestamp ranges
are, float and int64 should be treated the same way so as not to get
surprises due to implementation details.
It's a compile-time option that will change the semantics of
Jeff Davis pg...@j-davis.com writes:
On Tue, 2009-12-15 at 11:49 -0800, David Fetter wrote:
FWIW, I think it would be a good idea to treat timestamps as
continuous in all cases.
I disagree. There is a lot of value in treating timestamp ranges as
discrete.
One big reason is that the ranges
Scott Bailey arta...@comcast.net writes:
Ok, let me give an example of what we can do with the current
implementations that would not be possible with timestamps if we
implement as suggested. ...
The function below takes two period arrays that can have overlapping and
adjacent elements. It
Tom Lane wrote:
Jeff Davis pg...@j-davis.com writes:
On Tue, 2009-12-15 at 11:49 -0800, David Fetter wrote:
FWIW, I think it would be a good idea to treat timestamps as
continuous in all cases.
I disagree. There is a lot of value in treating timestamp ranges as
discrete.
One big reason
If this were an amazingly
short and beautiful piece of code, it might support your argument,
but it's neither.
Well we can't all be arrogant brainiacs.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
I wrote:
The proposed problem is certainly soluble without any assumptions
of discreteness.
To be concrete, I think it could be approached like this:
Assume the datatype provides a built-in function
period_except(p1 period, p2 period) returns setof period
which can return zero, one,
On Tue, 2009-12-15 at 17:17 -0500, Tom Lane wrote:
Actually, that is exactly one of the reasons why what you propose is
a *bad* idea. You want to institutionalize application dependence on
a non-portable implementation detail, namely the granularity of machine
representation of what's in
On 12/15/09 2:40 PM, Scott Bailey wrote:
If this were an amazingly
short and beautiful piece of code, it might support your argument,
but it's neither.
Well we can't all be arrogant brainiacs.
Tom, Scott,
Let's keep it constructive here. Thanks!
--Josh
--
Sent via pgsql-hackers
On Dec 15, 2009, at 5:40 PM, Jeff Davis wrote:
If you think I'm proposing that we drop inclusivity/exclusivity before
telling the application, that's not what I'm proposing at all. I'm
proposing that, at least in some circumstances, it's important to be
able to display the same value in
On Dec 15, 2009, at 11:34 AM, Jeff Davis wrote:
On Tue, 2009-12-15 at 10:19 -0500, Tom Lane wrote:
I'm not sure that anyone has argued that. I did suggest that there
might be a small list of types for which we should provide discrete
behavior (ie, with next/previous functions) and the rest
On Dec 15, 2009, at 3:40 PM, Jeff Davis wrote:
Based on the premise that timestamps are a continuous value and the
granularity/precision is entirely an implementation detail, you're
right. But I disagree with the premise, at least in some cases that I
think are worthwhile.
The argument is,
Tom Lane wrote:
I wrote:
The proposed problem is certainly soluble without any assumptions
of discreteness.
To be concrete, I think it could be approached like this:
Assume the datatype provides a built-in function
period_except(p1 period, p2 period) returns setof period
which can
On Tue, 2009-12-15 at 18:06 -0600, decibel wrote:
Now that varlena's don't have an enormous fixed overhead, perhaps it's
worth looking at using them. Obviously some operations would be
slower, but for your stated examples of auditing and history, I
suspect that you're not going to notice the
On Tue, 2009-12-15 at 18:03 -0600, decibel wrote:
I think it would help the discussion if you could provide some real
examples. I suspect you're thinking of things like scheduling apps,
where it's important to be able to do things like what's the next
available time slot?. There are probably
On Tue, 2009-12-15 at 16:08 -0800, Christophe Pettus wrote:
The argument is, in essence:
DECIMAL is continuous.
DECIMAL(10,3) is discrete.
timestamptz in general is a continuous value (unless we're talking
Planck times :) ). There is no way for us to guarantee that
Scott Bailey arta...@comcast.net wrote:
CREATE TYPE periodtz AS RANGE (timestamptz, '1 microsecond'::interval);
What does the second argument mean? Is it a default interval?
So basically I have a pg_range table to store the base typeid, a text
field for the granule value and the granule
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Sun, Dec 13, 2009 at 11:49:53PM -0800, Scott Bailey wrote:
I had proposed a temporal contrib module earlier and you wanted to see
support for many range types not just timestamptz [...]
So basically I have an anyrange pseudo type with the
On Mon, Dec 14, 2009 at 4:06 AM, to...@tuxteam.de wrote:
As another approach, what about storing typeid in typmod?
(Oid can be assumed to be stored in int32.)
For example,
CREATE TABLE tbl ( r range(timestamp) );
SELECT '[ 2.0, 3.0 )'::range(float);
There might be some overhead to
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Mon, Dec 14, 2009 at 06:02:04AM -0500, Robert Haas wrote:
On Mon, Dec 14, 2009 at 4:06 AM, to...@tuxteam.de wrote:
[...]
This looks more natural to me too.
It 's very different than the way we've traditionally used typmod,
though, which
Scott Bailey arta...@comcast.net writes:
So basically I have an anyrange pseudo type with the functions prev, next,
last, etc defined. So instead of hard coding range types, we would allow the
user to define their own range types. Basically if we are able to determine
the previous and next
On Sun, Dec 13, 2009 at 11:49:53PM -0800, Scott Bailey wrote:
So basically I have an anyrange pseudo type with the functions prev,
next, last, etc defined. So instead of hard coding range types, we would
allow the user to define their own range types. Basically if we are able
to
Scott Bailey arta...@comcast.net writes:
So basically I have an anyrange pseudo type with the functions prev,
next, last, etc defined. So instead of hard coding range types, we would
allow the user to define their own range types. Basically if we are able
to determine the previous and next
301 - 400 of 427 matches
Mail list logo
