Re: [HACKERS] Bug in pg_dump --table and --exclude-table fordeclarative partition table handling. - Mailing list pgsql-hackers

On Tue, May 9, 2017 at 4:21 AM, Jeevan Ladhe
<jeevan.ladhe@enterprisedb.com> wrote:
>> Current pg_dump --exclude-table option excludes partitioned relation
>> and dumps all its child relations and vice versa for --table option, which
>> I think is incorrect.
>>
>> In this case we might need to explore all partitions and exclude or
>> include
>> from dump according to given pg_dump option, attaching WIP patch proposing
>> same fix.   Thoughts/Comments?
>
> +1.
>
> Also, I can see similar issue exists with inheritance.

That's a pretty insightful comment which makes me think that this
isn't properly categorized as a bug.  Table partitioning is based on
inheritance and is intended to behave like inheritance except when
we've decided to make it behave otherwise.  We made no such decision
in this case, so it behaves like inheritance in this case.  So, this
is only a bug if the inheritance behavior is also a bug.

And I think there's a pretty good argument that it isn't.  Are we
saying we think that it was always intended that dumping an
inheritance parent would always dump its inheritance children as well,
and the code accidentally failed to achieve that?  Are we saying we'd
back-patch a behavior change in this area to correct the wrong
behavior we've had since time immemorial?  I can't speak for anyone
else, but I think the first is probably false and I would vote against
the second.

That's not to say that this isn't a possibly-useful behavior change.
I can easily imagine that users would find it convenient to be able to
dump a whole partitioning hierarchy by just selecting the parent table
rather than having to list all of the partitions.  But that's also
true of inheritance.  Is partitioning different enough from
inheritance that the two should have different behaviors, perhaps
because the partitioning parent can't contain data but the inheritance
parent could?  Or should we change the behavior for inheritance as
well, on the theory that the proposed new behavior is just plain
better than the current behavior and everyone will want it?  Or should
we do nothing at all, so as to avoid breaking things for the user who
says they want to dump JUST the parent and really means it?  Even if
the parent couldn't contain any rows, it's still got a schema that can
be dumped.  The option of changing partitioning in one patch and then
having a separate patch later that makes a similar change for
inheritance seems like the worst option, since then users might get
any of three behaviors depending on which release they have.  If we
want to change this, let's change it all at once.  But first we need
to get clarity on exactly what we're changing and for what reason.

There is a question of timing.  If we accept that this is not a bug
but a proposed behavior change, then it's not clear that it really
qualifies as an open item for v10.  I understand that there's an urge
to keep tinkering and making things better, but it's far from clear to
me that anything bad will happen if we just postpone changing anything
until v11, especially if we decide to change both partitioning and
inheritance.  I am somewhat inclined to classify this proposed open
item as a non-bug (i.e. a feature) but I'm also curious to hear what
others think.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company