On Wed, Jan 25, 2017 at 01:19:00PM -0500, Robert Haas wrote:
> On Wed, Jan 25, 2017 at 1:04 PM, Peter Eisentraut
> <peter.eisentraut@2ndquadrant.com> wrote:
> > On 1/18/17 2:32 PM, Robert Haas wrote:
> >> Unless we can find something official, I suppose we should just
> >> display BASE TABLE in that case as we do in other cases. I wonder if
> >> the schema needs some broader revision; for example, are there
> >> information_schema elements intended to show information about
> >> partitions?
> >
> > Is it intentional that we show the partitions by default in \d,
> > pg_tables, information_schema.tables? Or should we treat those as
> > somewhat-hidden details?
>
> I'm not really sure what the right thing to do is there. I was hoping
> you had an opinion.
The bulk of operations that work on traditional tables also work on partitions
and partitioned tables. The next closest kind of relation, a materialized
view, is far less table-like. Therefore, I recommend showing both partitions
and partitioned tables in those views. This is also consistent with the
decision to use words like "partition" and "partitioned" in messages only when
partitioning is relevant to the error. For example, ATWrongRelkindError()
distinguishes materialized views from tables, but it does not distinguish
tables based on their participation in partitioning.