Re: Declarative partitioning vs. information_schema
От | Amit Langote |
---|---|
Тема | Re: Declarative partitioning vs. information_schema |
Дата | |
Msg-id | 238c23ab-97c8-682a-2db3-73bf9ba84fbc@lab.ntt.co.jp обсуждение исходный текст |
Ответ на | Re: Declarative partitioning vs. information_schema (Noah Misch <noah@leadboat.com>) |
Список | pgsql-hackers |
On 2017/04/06 16:02, Noah Misch wrote: > 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. +1 Thanks, Amit
В списке pgsql-hackers по дате отправления: