On 5/25/16 8:19 PM, Craig Ringer wrote:
Postgres is well past the point where our relational features are the big selling point. It's now about scale, an incredibly robust storage engine, and all the extensiblity opportunities. We've moved from being an RDBMS to being a "Data Platform". Improving our OO capabilities just continues that.Right. I'm just not convinced table inheritance is a useful part of that picture.
In it's current state it's certainly not the best tool in the toolbox, but IMHO there's still plenty of room for the ability to support restricted polymorphism, because of all the benefits of not allowing willy-nilly stuff in the schema. There's certainly other cases (ie: per-customer custom fields) where willy-nilly is what you actually need.
And certainly things that reduce table modification pain for *any* operations are most welcome! I think allowing queued backgrounded processes would be a huge win there. If we had real stored procedures (IE: ability to control transaction state) and a modest background scheduler then it wouldn't be hard to build that.
-- Jim Nasby, Data Architect, Blue Treble Consulting, Austin TX Experts in Analytics, Data Architecture and PostgreSQL Data in Trouble? Get it in Treble! http://BlueTreble.com 855-TREBLE2 (855-873-2532) mobile: 512-569-9461 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
