Re: Declarative partitioning vs. information_schema - Mailing list pgsql-hackers

From Amit Langote
Subject Re: Declarative partitioning vs. information_schema
Date
Msg-id 238c23ab-97c8-682a-2db3-73bf9ba84fbc@lab.ntt.co.jp
Whole thread Raw
In response to Re: Declarative partitioning vs. information_schema  (Noah Misch <noah@leadboat.com>)
List 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 by date:

Previous
From: Kyotaro HORIGUCHI
Date:
Subject: Duplicate usage of tablespace location?
Next
From: Masahiko Sawada
Date:
Subject: Re: Interval for launching the table sync worker