On 06/15/2012 03:59 PM, Jeff Davis wrote: <blockquote cite="mid:1339743578.28986.19.camel@jdavis" type="cite"><pre
wrap="">OnWed, 2012-06-13 at 23:10 +0200, Miroslav Šimulčík wrote:
</pre><blockquote type="cite"><pre wrap="">I have working patch for postgresql version 9.0.4, but it needs
refactoring before i can submit it, because some parts don't
meet formatting requirements yet. And yes, changes are large, so it
will be better to discuss design first and then deal with code. Do you
insist on compatibility with standard SQL 2011 as Pavel wrote?
</pre></blockquote><pre wrap="">Try to work on solving the problem and identify the use cases. I don't
think the standard will cause a major problem, we should be able to make
the relevant parts of your patch match the standard.
That's one reason to work on it as an extension first: we can get a
better sense of the problem space and various use cases without worrying
about violating any standard. Then, as you need specific backend support
(e.g. special syntax), we can take the standards more seriously.
Regards,Jeff Davis
</pre></blockquote> What's wrong with SPI/timetravel extension for system versioning?<br /><a
href="http://www.postgresql.org/docs/9.1/static/contrib-spi.html">http://www.postgresql.org/docs/9.1/static/contrib-spi.html</a><br
/><br/> We are heavily using system-versioned and application-time period tables in our enterprise products (most of
themare bi-temporal). However our implementation is based on triggers and views and therefore is not very convenient to
use.There are also some locking issues with foreign keys to application-time period tables. It will be great if the new
temporalSQL features will be included in the Postgresql core with SQL 2011 syntax support. It is especially important
forbi-temporal tables because of complex internal logic of UPDATE/DELETE and huge SELECT queries for such tables.<br />
