Re: Inheritance

On 26 May 2016 at 01:56, Jim Nasby <Jim(dot)Nasby(at)bluetreble(dot)com> wrote:

> On 5/24/16 8:52 PM, Craig Ringer wrote:
> > Absolutely, and I use OO heavily. But a half-assed "object relational"
> > feature in the database that only kind-of works isn't OO, and it's
> > generally less useful than using existing relational-to-oo modelling
> > 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.

Oh, I totally agree there. It's almost as bad as people serialising Java
objects into the DB. Ugh. It's a bad, bad idea.

It's also what people seem to want to do, and I understand that somewhat
given the pain involved in full table rewrites under extended locks and the
hoop-jumping required to avoid them. It's particularly painful with
something app devs tend to need, but RDBMS designers prefer to ignore:
user-defined columns/attributes. Find me someone who *doesn't* want the
ability for their app users/deployers/etc to add arbitrary attributes to
customer records etc w/o code changes. jsonb helps a lot there, but you
lose Pg's type system and have to use a different query syntax etc.

Lower-pain ways to make schema changes and blend dynamic columns
(application-user-defined columns) with normal columns would help a lot
there. A pseudo-column that can store a TOASTable record extension that's a
set of colname/coltype/coltypmod . Storage is the relatively easy bit
though, the problem is how to work with that though the planner and
executor and output useful results...

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.
>

Agreed. A real PIVOT, especially one we can use as a source of tuples for
subqueries etc, would be really useful and is the sort of thing we'd need
some degree of dynamic column handling for.

> 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.

--
Craig Ringer http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services