Re: Partitioning WIP patch

On 27-02-2015 AM 03:01, Jim Nasby wrote:
> On 2/26/15 3:09 AM, Amit Langote wrote:
>> Unless I'm missing something again, isn't allowing partitions to have
>> heterogeneous rowtypes a problem in the long run? I'm afraid I'm
>> confused as to your stand regarding inheritance vs. new partitioning. To
>> be specific, children with heterogeneous schemas sounds much like what
>> inheritance would be good for as you say. But then isn't that why we
>> have to plan children individually which you said new partitioning
>> should get away from?
>
> Apologies if I haven't been clear enough. What I'd like to see is the
> best of both worlds; fast partitioning when not using inheritance, and
> perhaps somewhat slower when using inheritance, but still with the
> features partitioning gives you.
>

I get the distinction, thanks.

Actually I wasn't quite thinking of altering the way any part of the
current partitioning based on inheritance works nor am I proposing to
get rid of it. It all stays as is. Not sure how we could say if it will
support features of the new partitioning before those features actually
begin to materialize.

> But my bigger concern from a project standpoint is that we not put
> ourselves in a position of supporting something that we really don't
> want to support (a partitioning system that's got inheritance mixed in).
> As much as I'd personally like to have both features together, I think
> it would be bad for the community to go down that road without careful
> thought.
>
>> Yes, it does. In fact, I do intend to keep them separate the first
>> attempt of which is to choose to NOT transform a PARTITION OF parent
>> clause into INHERITS parent. Any code that may look like it's trying to
>> do that is because the patch is not fully baked yet.
>
> Ok, good to know. That's why I was asking about ALTER TABLE ADD COLUMN
> on a partition. If we release something without that being restricted
> it'll probably cause trouble later on.

Yes, I agree. More generally, I think the patch/approach is in need of a
clear separation of internal implementation concerns and user-facing
notions even at this point. This may be one of them. For example, with
the patch, a partition is defined as:

CREATE "TABLE" name PARTITION OF parent ...

Unless that turns into something like:

CREATE PARTITION name OF parent ...

we may not be able to put all the restrictions we'd want to put on a
partition for the sake of what would be partitioning internals.

Thanks,
Amit