Temporal Data Management in PostgreSQL: Past, Present, and Future
Formal Metadata
| Title | Temporal Data Management in PostgreSQL: Past, Present, and Future |
|
| Alternative Title | Range Types and Temporal: Past, Present, and Future |
|
| Title of Series | |
| Number of Parts | 20 |
| Author | |
| Contributors | |
| License | You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal and non-commercial purpose as long as the work is attributed to the author in the manner specified by the author or licensor and the work or content is shared also in adapted form only under the conditions of this license. |
| Identifiers | |
| Publisher | |
| Release Date | |
| Language | |
| Producer | |
Content Metadata
| Subject Area | |
| Genre | |
| Abstract | Range Types and Temporal: Past, Present, and Future
Range Types didn't exist before, why do we need them now? How do they work? Why is "Temporal" important if we already have timestamps? How do we apply these concepts before deploying PostgreSQL 9.2? What's left to be done, and what solutions are in the works?
I'll be asking the audience these questions, so -- Err... I mean: I will be answering these questions during the talk.
Extensions, changes to core postgresql, and future ideas will be described in the context of solving a simple use case from 2006. These ideas build up to the larger point that powerful types are important, and database systems should do more to support them. |
|