Range types
in [PgSql]
|
Prev: Winflex
Next: [HACKERS] Fast or immediate shutdown
From: Martijn van Oosterhout on 14 Dec 2009 08:39 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 determine the previous and next values of the base types we'd be able > to define a range type. I'm envisioning in a manner much like defining > an enum type. I find it odd that you could define functions next() and prev() since that assumes some kind of dicretisation which simply does not exist for most types I can think of. It would seem to me the real useful uses of ranges would be the operations overlaps, disjoint, proceeds, follows, etc, which could all be defined on any well-ordered type (wherever greater-than and less-than are well defined). No need to discretise anything. Do you have any actual usecase for a distretized range type for timestamp? Have a nice day, -- Martijn van Oosterhout <kleptog(a)svana.org> http://svana.org/kleptog/ > Please line up in a tree and maintain the heap invariant while > boarding. Thank you for flying nlogn airlines.
From: Tom Lane on 14 Dec 2009 09:58 Scott Bailey <artacus(a)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 values of the base types we'd be able > to define a range type. I'm envisioning in a manner much like defining > an enum type. I think array types, not enums, would be a better model. The real question is how the heck granularity enters into it. Why should a range type require that? I think you are mixing up two concepts that would be better kept separate. In particular, the granularity examples you give seem to assume that the underlying datatype is exact not approximate --- which among other things will mean that it fails to work for float timestamps. Since timestamps are supposedly the main use-case, that's pretty troubling. 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 10:01 Takahiro Itagaki <itagaki.takahiro(a)oss.ntt.co.jp> writes: > As another approach, what about storing typeid in typmod? > (Oid can be assumed to be stored in int32.) No, it cannot --- you'd be one bit short. The general rule for typmod is that all negative values are treated as "unspecified". Even if you managed to find and change every place that assumed that, you'd still have a failure for -1, which is a perfectly legal value of Oid. 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 10:16 Robert Haas <robertmhaas(a)gmail.com> writes: > On Mon, Dec 14, 2009 at 4:06 AM, <tomas(a)tuxteam.de> wrote: >>> As another approach, what about storing typeid in typmod? >>> (Oid can be assumed to be stored in int32.) > It 's very different than the way we've traditionally used typmod, Aside from the problems already pointed out, there's another: this definition usurps the ability to attach a typmod to the range's base type. Again, you should be looking at arrays not enums for a reference example. The typmod of an array feeds through to its element type. 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: Scott Bailey on 14 Dec 2009 11:20
Martijn van Oosterhout wrote: > 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 determine the previous and next values of the base types we'd be able >> to define a range type. I'm envisioning in a manner much like defining >> an enum type. > > I find it odd that you could define functions next() and prev() since > that assumes some kind of dicretisation which simply does not exist for > most types I can think of. Because intervals (mathematical not SQL) can be open or closed at each end point we need to know what the next an previous value would be at the specified granularity. And while you can do some operations without knowing this, there are many you can't. For instance you could not tell whether two [] or () ranges were adjacent, or be able to coalesce an array of ranges. > It would seem to me the real useful uses of ranges would be the > operations overlaps, disjoint, proceeds, follows, etc, which could all > be defined on any well-ordered type (wherever greater-than and > less-than are well defined). No need to discretise anything. > > Do you have any actual usecase for a distretized range type for > timestamp? -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers |