Range types
in [PgSql]
|
Prev: Winflex
Next: [HACKERS] Fast or immediate shutdown
From: Scott Bailey on 14 Dec 2009 15:44 Tom Lane wrote: > 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. I think dates could be added to that list as well. But any implementation that doesn't do ranges of timestamptz are non-starters as far as I'm concerned. Certainly int64 timestamps and numeric are doable. And Jeff's period implementation supports float timestamps. I never use float timestamps so I can only assume that he made it work. Personally, I'd rather just see float timestamps go away. And if the range types never supported float or float timestamps, I'd be ok with that. Scott -- 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 18:45 Scott Bailey <artacus(a)comcast.net> writes: > Tom Lane wrote: >> If the only interesting use-cases are ints and enums, maybe we could >> just hard-wire it. > I think dates could be added to that list as well. Good point. Network addresses too probably. > But any implementation that doesn't do ranges of timestamptz are > non-starters as far as I'm concerned. Oh, I quite agree --- I'm just complaining about trying to force timestamps into a discrete model that they don't fit. What I was trying to suggest was that we could hard-wire a mechanism that says ints and a few other predetermined cases are discrete while everything else is treated as continuous. > Personally, I'd rather just see float timestamps go away. That's more or less irrelevant to my point. A large fraction of the datatypes in Postgres do not have discrete behavior. Reals, numerics, timestamps, strings, bitstrings, geometrics. Not to mention arrays and composites. Creating an artificial granularity is simply the wrong way to approach it, even for those types where there's an implementation artifact that allows you to make it sort-of-work. 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: tomas on 15 Dec 2009 00:26 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Mon, Dec 14, 2009 at 01:32:08PM -0500, Tom Lane wrote: [...] > (Also, stuff like strings simply doesn't have any sane concept of a > unique next or previous value. If you are willing to limit the length, then yes, you could consider them discrete too, but... > I think the number of types that are > really discrete in this sense is very small, like maybe just ints and > enums.) ....I do agree that ranges over continuous types are the more "interesting"[1] (and possibly more useful) beast. - --------- [11] Unfortunaltel they could turn out to be "interesting" in the sense of "may you live in interresting times" ;-) Regards - -- tomás -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFLJx3xBcgs9XrR2kYRAn10AJ9f/MQiz45LS7ogsRmMXpawcOWSfgCggkWG gFev/SS09O+IOO+FB3shav0= =KwxB -----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: tomas on 15 Dec 2009 02:28 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Mon, Dec 14, 2009 at 11:09:16AM -0800, Jeff Davis wrote: [...] > I think "countable" is a more accurate word than "discrete". Strings are > discrete but not countable. Oh, no -- strings (of finite, but arbitrary length) are not discrete -- you can always squeeze one more between two given strings. In this sense there are quite similar to rational numbers. Can we call them continuous? -- it depends, it seems that the terminology here isn't consistent: sometimes the rationals are considered continuous (as per the property above mentioned), sometimes the reals (which are a much more monstrous construct!) are referred to as "the continuum". As Robert points out, they are countable; you'd need infinite length for them to be more than that (then they would behave a bit like the reals, Cantor diagonal and all that ;-) All that said, it's moot: in computers, we can't represent strings of arbitrary length (PostgreSQL has an upper limit of about 1GB, right?). 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 it's all implementation-dependent (nastier). But given an implementation, the concept of "next" and "previous" on floats is (if you give me some slack with NANs) mostly well-defined. Same with strings (up-to) some fixed length. Still, it seems non-discrete is a useful abstraction? Regards - -- tomás -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFLJzqSBcgs9XrR2kYRAoydAJ9uUYt4aTj+BjuJv9XtDIU7UAAFjwCbBBSv gkw3a6oTqGOoQBHiuZjcJvQ= =l9YV -----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: Greg Stark on 15 Dec 2009 08:09
On Tue, Dec 15, 2009 at 7:28 AM, <tomas(a)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 it's all implementation-dependent > (nastier). But given an implementation, the concept of "next" and > "previous" on floats is (if you give me some slack with NANs) mostly > well-defined 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. -- greg -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers |