Range types
in [PgSql]
|
Prev: Winflex
Next: [HACKERS] Fast or immediate shutdown
From: tomas on 15 Dec 2009 09:10 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Tue, Dec 15, 2009 at 01:09:02PM +0000, 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 "next" float by just > incrementing your float as an 64-bit integer. Yes that raises your > value by a different amount, and it's still useful. Didn't know that -- thanks :-) (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). Regards - -- tomás -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFLJ5i+Bcgs9XrR2kYRAqtUAJ0VHeUd7q/+Xr9H+Clbr2E0HVV3mgCdFXZM /EPDk1B+M2uP6/Lqr50Rv4k= =XICC -----END PGP SIGNATURE----- -- 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 15 Dec 2009 09:52 tomas(a)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. 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 15 Dec 2009 09:58 Greg Stark <gsstark(a)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 raises your > value by a different amount, and it's still useful. There are certainly some low-level numerical analysis situations where you want to get the "next" float value, but that hardly constitutes an argument for treating ranges of floats as discrete rather than continuous. Normal users of a range datatype aren't going to be interested in dealing with that sort of inherently machine-specific behavior. Even in types where next/previous are well defined, I'm not that comfortable with having range operations depend on them. What happens when one end of your range is INT_MIN or INT_MAX? 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: Robert Haas on 15 Dec 2009 10:06 On Tue, Dec 15, 2009 at 9:58 AM, Tom Lane <tgl(a)sss.pgh.pa.us> wrote: > Greg Stark <gsstark(a)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 raises your >> value by a different amount, and it's still useful. > > There are certainly some low-level numerical analysis situations where > you want to get the "next" float value, but that hardly constitutes > an argument for treating ranges of floats as discrete rather than > continuous. Normal users of a range datatype aren't going to be > interested in dealing with that sort of inherently machine-specific > behavior. Yeah, I don't think we want to base this feature on something that arcane. 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 don't think it's going to turn out to be all that small. ....Robert -- 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: Nicolas Barbier on 15 Dec 2009 10:16
2009/12/15 Tom Lane <tgl(a)sss.pgh.pa.us>: > tomas(a)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. 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 lexicographical ordering. I don't think it is possible to get anything in between those two strings. Nicolas -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers |