<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
		>
<channel>
	<title>Comments on: Temporal PostgreSQL Roadmap</title>
	<atom:link href="http://thoughts.j-davis.com/2010/03/09/temporal-postgresql-roadmap/feed/" rel="self" type="application/rss+xml" />
	<link>http://thoughts.j-davis.com/2010/03/09/temporal-postgresql-roadmap/</link>
	<description>Ideas on Databases, Logic, and Language by Jeff Davis</description>
	<lastBuildDate>Tue, 18 Oct 2011 07:43:52 +0000</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.2.1</generator>
	<item>
		<title>By: Oleg Bartunov</title>
		<link>http://thoughts.j-davis.com/2010/03/09/temporal-postgresql-roadmap/comment-page-1/#comment-1483</link>
		<dc:creator>Oleg Bartunov</dc:creator>
		<pubDate>Wed, 20 Apr 2011 13:27:31 +0000</pubDate>
		<guid isPermaLink="false">http://thoughts.j-davis.com/?p=254#comment-1483</guid>
		<description>Fuzzy date, fuzzy interval, Allen&#039;s algebra,...,etc. This is a big and separate topic.  I&#039;m thinking about hdate data type for historical data and looks like it should looks like,
{date1,date2, pdate1,pdate2,...,pdateN}, where date1,date2 - are dates to represent fuzzy date and pdates are probable dates, ordered by reliability. Example:  in the beginning of 20-th century, but most probable in 1925 or 1927 year. Then, we could store this like: {01-01-1900,31-12-1999, 01-01-1925,31-12-1925,01-01-1927,31-13-1927}. pdates here represents as two dates, since they are fuzzy.</description>
		<content:encoded><![CDATA[<p>Fuzzy date, fuzzy interval, Allen&#8217;s algebra,&#8230;,etc. This is a big and separate topic.  I&#8217;m thinking about hdate data type for historical data and looks like it should looks like,<br />
{date1,date2, pdate1,pdate2,&#8230;,pdateN}, where date1,date2 &#8211; are dates to represent fuzzy date and pdates are probable dates, ordered by reliability. Example:  in the beginning of 20-th century, but most probable in 1925 or 1927 year. Then, we could store this like: {01-01-1900,31-12-1999, 01-01-1925,31-12-1925,01-01-1927,31-13-1927}. pdates here represents as two dates, since they are fuzzy.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Jeff Davis</title>
		<link>http://thoughts.j-davis.com/2010/03/09/temporal-postgresql-roadmap/comment-page-1/#comment-199</link>
		<dc:creator>Jeff Davis</dc:creator>
		<pubDate>Thu, 11 Mar 2010 04:54:05 +0000</pubDate>
		<guid isPermaLink="false">http://thoughts.j-davis.com/?p=254#comment-199</guid>
		<description>This can be modeled in a way similar to numbers with only a few significant figures: truncation.

For example, you can use a CHECK constraint like &quot;CHECK(the_month = date_trunc(&#039;month&#039;, the_month))&quot;. This might be a good use for domains.</description>
		<content:encoded><![CDATA[<p>This can be modeled in a way similar to numbers with only a few significant figures: truncation.</p>
<p>For example, you can use a CHECK constraint like &#8220;CHECK(the_month = date_trunc(&#8216;month&#8217;, the_month))&#8221;. This might be a good use for domains.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Scott Bailey</title>
		<link>http://thoughts.j-davis.com/2010/03/09/temporal-postgresql-roadmap/comment-page-1/#comment-198</link>
		<dc:creator>Scott Bailey</dc:creator>
		<pubDate>Thu, 11 Mar 2010 04:46:44 +0000</pubDate>
		<guid isPermaLink="false">http://thoughts.j-davis.com/?p=254#comment-198</guid>
		<description>Richard,

You can install &lt;a href=&quot;http://sourceforge.net/projects/chronosdb/&quot; rel=&quot;nofollow&quot;&gt;chronosDB&lt;/a&gt; over top of Jeff&#039;s period data type. ChronosDB does things like union, minus and intersect non-contiguous sets (arrays of periods)</description>
		<content:encoded><![CDATA[<p>Richard,</p>
<p>You can install <a href="http://sourceforge.net/projects/chronosdb/" rel="nofollow">chronosDB</a> over top of Jeff&#8217;s period data type. ChronosDB does things like union, minus and intersect non-contiguous sets (arrays of periods)</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Richard Broersma Jr.</title>
		<link>http://thoughts.j-davis.com/2010/03/09/temporal-postgresql-roadmap/comment-page-1/#comment-197</link>
		<dc:creator>Richard Broersma Jr.</dc:creator>
		<pubDate>Wed, 10 Mar 2010 23:02:25 +0000</pubDate>
		<guid isPermaLink="false">http://thoughts.j-davis.com/?p=254#comment-197</guid>
		<description>Yes, either overlapping or touching (is overlapping the same a touching?). Having this would make be a really nice feature that (to me) would simply range queries.</description>
		<content:encoded><![CDATA[<p>Yes, either overlapping or touching (is overlapping the same a touching?). Having this would make be a really nice feature that (to me) would simply range queries.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: David Fetter</title>
		<link>http://thoughts.j-davis.com/2010/03/09/temporal-postgresql-roadmap/comment-page-1/#comment-196</link>
		<dc:creator>David Fetter</dc:creator>
		<pubDate>Wed, 10 Mar 2010 20:59:40 +0000</pubDate>
		<guid isPermaLink="false">http://thoughts.j-davis.com/?p=254#comment-196</guid>
		<description>By &quot;continuous ranges,&quot; do you mean something that knows that &quot;melts&quot; two or more overlapping, non-identical intervals into their union?  That sounds really neat!</description>
		<content:encoded><![CDATA[<p>By &#8220;continuous ranges,&#8221; do you mean something that knows that &#8220;melts&#8221; two or more overlapping, non-identical intervals into their union?  That sounds really neat!</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Joe</title>
		<link>http://thoughts.j-davis.com/2010/03/09/temporal-postgresql-roadmap/comment-page-1/#comment-195</link>
		<dc:creator>Joe</dc:creator>
		<pubDate>Wed, 10 Mar 2010 17:29:17 +0000</pubDate>
		<guid isPermaLink="false">http://thoughts.j-davis.com/?p=254#comment-195</guid>
		<description>Not sure if this falls into TEMPORAL data types, but I&#039;ve found a need for what I call a FUZZY DATE.  For example, a blog post may have a precise date, like 2010/03/09, and you may know the precise date of a person&#039;s birth or some other event.  However, some events or dates are less precise, e.g., a monthly magazine may have a publication date of March 2010, a quarterly journal may be dated Winter 2010, a book may have simply have a year as copyright date, and sometimes you may only know a historical date only approximately, e.g., circa 1502.  You&#039;d still like to order the events/date in some reasonable manner or search for events that took place in March 2010 and find the journal, the magazine and the blog post.</description>
		<content:encoded><![CDATA[<p>Not sure if this falls into TEMPORAL data types, but I&#8217;ve found a need for what I call a FUZZY DATE.  For example, a blog post may have a precise date, like 2010/03/09, and you may know the precise date of a person&#8217;s birth or some other event.  However, some events or dates are less precise, e.g., a monthly magazine may have a publication date of March 2010, a quarterly journal may be dated Winter 2010, a book may have simply have a year as copyright date, and sometimes you may only know a historical date only approximately, e.g., circa 1502.  You&#8217;d still like to order the events/date in some reasonable manner or search for events that took place in March 2010 and find the journal, the magazine and the blog post.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Richard Broersma Jr.</title>
		<link>http://thoughts.j-davis.com/2010/03/09/temporal-postgresql-roadmap/comment-page-1/#comment-194</link>
		<dc:creator>Richard Broersma Jr.</dc:creator>
		<pubDate>Wed, 10 Mar 2010 12:41:04 +0000</pubDate>
		<guid isPermaLink="false">http://thoughts.j-davis.com/?p=254#comment-194</guid>
		<description>One lesser feature that I believe may be useful would be range aggregates.  Rather than simply summing the durations of a range for a group, it would be nice to get a set of continuous ranges for the group.</description>
		<content:encoded><![CDATA[<p>One lesser feature that I believe may be useful would be range aggregates.  Rather than simply summing the durations of a range for a group, it would be nice to get a set of continuous ranges for the group.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: akretschmer</title>
		<link>http://thoughts.j-davis.com/2010/03/09/temporal-postgresql-roadmap/comment-page-1/#comment-193</link>
		<dc:creator>akretschmer</dc:creator>
		<pubDate>Wed, 10 Mar 2010 06:20:48 +0000</pubDate>
		<guid isPermaLink="false">http://thoughts.j-davis.com/?p=254#comment-193</guid>
		<description>I have seen a very interesting presentation from Magnus Hagander (at FOSDEM 2010 Brussels) about this great feature - and i hope, 9.1 will contains this great feature. 

I wish you success!

Regards, Andreas</description>
		<content:encoded><![CDATA[<p>I have seen a very interesting presentation from Magnus Hagander (at FOSDEM 2010 Brussels) about this great feature &#8211; and i hope, 9.1 will contains this great feature. </p>
<p>I wish you success!</p>
<p>Regards, Andreas</p>
]]></content:encoded>
	</item>
</channel>
</rss>

