On 5/24/16 8:52 PM, Craig Ringer wrote:> Absolutely, and I use OO heavily. But a half-assed "object relational">
featurein the database that only kind-of works isn't OO, and it's> generally less useful than using existing
relational-to-oomodelling> techniques like FK-related 1:1 child tables for specialisation.
How is it less useful than that? To me, the FK "solution" is the
absolute worst of everything: you still have all the separate child
tables that you must explicitly query *and* you have to get all the
joins correct as well. And hope it doesn't have horrible performance.
> Note that there was enough enthusiasm to adopt whole new database
> engines, but not enough to use PostgreSQL's existing features for that.
> Partly because they suck. In particular, people looking for this tend to
> want to be able to create new subtypes without having to mess around
> making schema changes and modelling everything.
Which is a decision people have come to regret, because then your
codebase somehow has to deal with 38 different versions of what a
"customer" is.
> There's much more future in improving document-structured storage like
> jsonb, and possibly extending in future toward hybrid storage with some
> normal cols and some dynamic cols, than with Pg's
> pseudo-object-relational inheritance feature.
I don't see why we can't do both. There's many cases where more
flexibility in what output tuples look like would be very valuable. The
JSON features are one aspect; crosstab is another.
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.
--
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