PGCon2014 - Final Release
PGCon 2014
The PostgreSQL Conference
| Speakers | |
|---|---|
|
Jeff Davis |
| Schedule | |
|---|---|
| Day | Talks - Day 1 - Thu May 22 - 2014-05-22 |
| Room | Morisset 256 |
| Start time | 13:00 |
| Duration | 00:45 |
| Info | |
| ID | 716 |
| Event type | Lecture |
| Track | Advanced Features |
| Language used for presentation | English |
PostgreSQL, Range Types, and Rust
Combining database features with language features
Range Types, introduced in PostgreSQL 9.2, are an important feature for scheduling and other applications. Range Types allow much more efficient queries on ranges (e.g. ranges of time) such as "overlaps" and "contains", are less error-prone, and offer the critical "non-overlapping" constraint (useful for preventing schedule conflicts).
But to make use of any advanced database features, good support in the client language is crucial. Many people use libraries to translate between database types and types in the client language -- not only is that convenient, but it contributes to safety and reduces the chance for simple errors.
Rust is a powerful new language with a lot to offer, including a postgres driver that supports Range Types as first-class types. I'll be discussing how rust libraries help bridge the gap between advanced database features and practical application development.
The speed of development in PostgreSQL can often outpace the ecosystem surrounding it. Performance-boosting features are used as quickly as administrators upgrade, but extensions to the SQL language take more time. Without support in the client language, SQL language features are only used by early-adopters who are willing to put up with the rough edges.
As the primary developer for Range Types, I feel that their utility would be greatly increased with greater accessibility for simple applications. The problem they solve -- largely the problem of scheduling -- is prevalent in such applications.
Rust makes a great example of how to better integrate data types into the client language. It's got Option types, which are great for handling edge cases and special values (like an empty or unbounded range); it's fast enough that the driver can be written in rust, which avoids the need for a dependency on libpq-dev and enables a little more creativity; and it's got a great community.
In particular, I'd like to credit Steven Fackler (https://github.com/sfackler) who wrote the native rust-postgres driver, as well as the Range Types support!
This presentation does not assume any prior knowledge of the rust language.