Re: WIP patch (v2) for updatable security barrier views

On 28 January 2014 21:28, Robert Haas <robertmhaas@gmail.com> wrote:
> On Tue, Jan 28, 2014 at 5:02 AM, Simon Riggs <simon@2ndquadrant.com> wrote:
>> I agree that this is being seen the wrong way around. The planner
>> contains things it should not do, and as a result we are now
>> discussing enhancing the code that is in the wrong place, which of
>> course brings objections.
>>
>> I think we would be best served by stopping inheritance in its tracks
>> and killing it off. It keeps getting in the way. What we need is real
>> partitioning. Other uses are pretty obscure and we should re-examine
>> things.
>
> I actually think that inheritance is a pretty good foundation for real
> partitioning.  If we were to get rid of it, we'd likely end up needing
> to add most of the same functionality back when we tried to do some
> kind of real partitioning later, and that doesn't sound fun.  I don't
> see any reason why some kind of partitioning syntax couldn't be added
> that leverages the existing inheritance mechanism but stores
> additional metadata allowing for better optimization.
>
> Well... I'm lying, a little bit.  If our chosen implementation of
> "real partitioning" involved some kind of partition objects that could
> be created and dropped but never directly accessed via DML commands,
> then we might not need anything that looks like the current planner
> support for partitioned tables.  But I think that would be a
> surprising choice for this community.  IMV, the problem with the
> planner and inheritance isn't that there's too much cruft in there
> already, but that there are still key optimizations that are missing.
> Still, I'd rather try to fix that than start over.
>
>> In the absence of that, releasing this updateable-security views
>> without suppport for inheritance is a good move. It gives us most of
>> what we want now and continuing to have some form of restriction is
>> better than having a much greater restriction of it not working at
>> all.
>
> -1.  Inheritance may be a crappy substitute for real partitioning, but
> there are plenty of people using it that way.

When I talk about removing inheritance, of course I see some need for
partitioning.

Given the way generalised inheritance works, it is possible to come up
with some monstrous designs that are then hard to rewrite and plan.

What I propose is that we remove the user-visible generalised
inheritance feature and only allow a more structured version which we
call partitioning. If all target/result relations are identical it
will be much easier to handle things because there'll be no special
purpose code to juggle.

Yes, key optimizations are missing. Overburdening ourselves with
complications that slow us down from delivering more useful features
is sensible. Think of it as feature-level refactoring, rather than the
normal code-level refactoring we frequently discuss.

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