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.eisentr...@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. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
