Holy shit. Why hasn't anyone talked about it sooner? I've seen literally dozens of tables with
Rails even supports it!
It's a bit of an issue for something offering unique or novel features, because there's the risk no one will ever find them.
I'd possibly think that most people also just go "we'll use a db" and pick from mysql and postgres (probably based on which one comes to mind first for them), but don't ever think about it any more than that.
I wonder whether an official "cool things you possibly don't know about (and when/why they're useful)" page could help? Or maybe a "designing a schema/model? here a some features that might make your life better" page could help spread the word? Postgres is lucky to have Craig as an advocate, and I love reading everything he writes, but maybe someone just getting exposed to Postgres doesn't know to look at Craig's stuff? (Although, maybe Google rankings would make this page appear early enough to do a great service...)
I was talking to another dev (who's very experienced) about dbs and I said I'd always expect to go postgres because of the extra features (and intentionally tightly couple to it) and the response was "yeah but how often do you actually use them" which initially shocked me (answer was "all the time"....), but now that I think about it; it's probably a pretty common perspective...
Of course... I'd welcome more reading my blog, at the same time there are a lot of others that introduce good Postgres content to the world. This was my biggest goal in starting to curate Postgres weekly (http://www.postgresweekly.com) which focuses on Postgres for app devs. There's a ton in Postgres, which 9 years into spending way too much time with Postgres I'm still discovering each week so trying to help make a better way for others to learn was key.
Sadly the hard part about the cool things isn't the most important. Cool gets a lot of attention, but the really safe and stable things like transactional DDL, rich indexing, MVCC all that doesn't get as much love as hstore, JSONB, or HyperLogLog which is a shame cause they're really important when you're running a real business which cares about data integrity.
A hugely useful feature of postgres, that nearly no ORM/ActiveRecord library makes use of, is the RETURNING clause of INSERT statements (also supported on UPDATE and DELETE statements, though those are less useful).
A write statement with a RETURNING clause returns a resultset just like SELECT, with one row per row inserted, updated, or deleted. In this way, you can request the values of columns whose data was dynamically determined by the postgres server. This is especially useful for sequence (ie: SERIAL, autoincrement) values, as well as other columns with default values (such as an insert datetime, or a column with a value based on a complex expression).
This functionality is amazing, yet is so underused. Try to do a multi-row insert statement with MySQL with an auto-increment primary key, and know which IDs were assigned to your rows. You can't, because there is no guarantee your auto-increment values will be sequential.
Example query, which will return the auto-increment sequence id and default insertion timestamp of the two inserted rows:
INSERT INTO members (name) VALUES ('Foo'), ('Bar') RETURNING id, created_at;
The anti ORM movement convinced only a few interested database users.
It's because of the Django docs that I've learned about a few of those awesome fields types.
IMO this was because they were too dogmatic and ignored the things ORM's did better, focusing on performance that didn't matter or on issues that come up even when you don't use an ORM (n+1 in the architecture).
That said, I don't think anyone that hasn't learned SQL really don't understand their ORM either. It's one of the fundamentals that any developer should know before they ever write production code.
Hopefully the partitioning thing is soon fixed 'properly'.
And the end of the day, they ended up selecting all the start and end dates and then building their own interval tree ( https://en.wikipedia.org/wiki/Interval_tree ) and doing overlap detection themselves.
If they were using a database with good stored procedure support and had the skills to write the stored procedure or function in the database, they might then fight with writing the overlap detection there... but they likely found it a profoundly unpleasant experience.
And then here's PostgreSQL. It has it native. Hours, days, weeks of time spent writing, testing, debugging and otherwise fighting with this problem now suddenly become something along the lines of "SELECT isempty(daterange('2017-04-30', '2017-05-07')) FROM reservations" or something to that effect.
It represents a significant time savings when you need it for things that are more interesting than reimplementing data structures that aren't in the standard libraries.
create table reservation1 (duration tstzrange);
select * from reservation1 where duration && '[2017-04-30, 2017-05-07]';
create table reservation2 (start timestamptz, stop timestamptz, check (start <= stop));
select * from reservation2 where '2017-04-30' <= stop and start <= '2017-05-07';
create table reservation1 (duration tsrange, exclude using gist (duration with &&));
insert into reservation1 values ('[2017-04-30, 2017-05-07]'); -- ok
insert into reservation1 values ('[2017-05-10, 2017-05-12]'); -- ok
insert into reservation1 values ('[2017-05-05, 2017-05-08]'); -- error!
No index (start, stop) 123ms
Btree index (start, stop) 29ms
GIST index (duration) 0.2ms
create table reservation (room text, duration tstzrange);
insert into reservation (room, duration) values
('A100', '[2017-04-30, 2017-05-07]'),
('A100', '[2017-05-10, 2017-05-12]');
create view my_orm_sucks (room, start, stop) as
select room, lower(duration), upper(duration) from reservation;
select * from my_orm_sucks;
room | start | stop
A100 | 2017-04-30 00:00:00-07 | 2017-05-07 00:00:00-07
A100 | 2017-05-10 00:00:00-07 | 2017-05-12 00:00:00-07
update my_orm_sucks set room = 'FM200' where room = 'A100';
select * from reservation;
room | duration
FM200 | ["2017-04-30 00:00:00-07","2017-05-07 00:00:00-07"]
FM200 | ["2017-05-10 00:00:00-07","2017-05-12 00:00:00-07"]
Or better yet, fix the driver or ORM!
Not nearly as mature libs as Java.
CREATE TABLE reservations (
EXCLUDE USING gist (room WITH =, during WITH &&)
CREATE TABLE reservations (
EXCLUDE USING gist (room WITH =, tstzrange(start, stop, '') WITH &&)