Range types
in [PgSql]
|
Prev: Winflex
Next: [HACKERS] Fast or immediate shutdown
From: Andrew Dunstan on 14 Dec 2009 14:53 Tom Lane wrote: >> We can ask the user to provide a prior() and next() function, and if >> they aren't provided, we assume it's continuous. >> > > Well, that still leaves us with the problem that Joe Schmo will file > a bug when "create function next(float4) returns float4 as > $$ select $1 + 0.00001 $$" doesn't behave sanely for him. I'd prefer > not to leave it to the user to decide whether a type is discrete or > not. The traffic on pgsql-bugs is convincing evidence that a very > large fraction of our user-base doesn't understand that floats are > inexact :-( > Indeed. > >> I think "countable" is a more accurate word than "discrete". Strings are >> discrete but not countable. >> > > It's been too long since college math classes for me to be sure whether > "discrete" is really the exact term here. But I'm even more suspicious > of "countable". I think a suitable diagonalization argument might show > that strings are countable. That's getting a bit off-topic though... > > > Right, I don't think strings are any more or less countable than integers. (and yes, it's a bit OT). Surely the issue from our POV is whether, given two distinct members of a class, we can ever say there is not any intervening member of the class according to some ordering. If we can't then next() and prior() make no sense for that class. cheers andrew -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Tom Lane on 14 Dec 2009 14:55 Jeff Davis <pgsql(a)j-davis.com> writes: > On Mon, 2009-12-14 at 14:23 -0500, Tom Lane wrote: >> I'd prefer not to leave it to the user to decide whether a type is >> discrete or not. > I don't know how we can decide such a thing. Do you have any ideas? If the only interesting use-cases are ints and enums, maybe we could just hard-wire it. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Tom Lane on 14 Dec 2009 15:05 Andrew Dunstan <andrew(a)dunslane.net> writes: > Surely the issue from our POV is whether, given two distinct members of > a class, we can ever say there is not any intervening member of the > class according to some ordering. If we can't then next() and prior() > make no sense for that class. We would also like to be sure that the answer is not machine-dependent. For example, you can make such an assertion for two normalized floats that differ by 1 unit in the last place --- but with a different float implementation the answer could be different, and anyway a lot of the really serious problems with float ranges would stem from the range boundary value probably not being exactly what the user thinks it is. Also, it's not just "some ordering" that's of interest, it's the natural one for the datatype. The reason the countability of strings isn't relevant to us here is that diagonalization or dovetailing counts them in an ordering that people wouldn't want in practice. But that brings up something that actually is interesting: should the range mechanism have a way to identify which btree opclass is considered to define the type's sort order? Or is it enough to provide ranges in the type's default ordering? regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Nathan Boley on 14 Dec 2009 15:12 > Right, I don't think strings are any more or less countable than integers. > (and yes, it's a bit OT). Well, if I remember my algebra, I think the issue is that integers are locally finite whereas strings are not ( assuming standard orderings, of course ). -Nathan -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Tom Lane on 14 Dec 2009 15:29
Scott Bailey <artacus(a)comcast.net> writes: > I was referring to the syntax for how the user actually defined an enum > not about it's implementation. Basically what I was hoping to get out of > this thread was whether it was better to allow the user to define their > own range types by specifying the base type and possibly the granularity > and default inclusiveness of the end points, or if we should just > provide the types like period and intrange? If 99% of the usefulness will come from ranges over a fixed set of datatypes, it might be best to just do that. That last 1% would be very expensive to get, when you consider all the infrastructure that would be involved with an extensible definition. If we think there's a lot of usefulness for ranges over user-defined types, then this argument doesn't help ... regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers |