Re: Declarative partitioning vs. information_schema

On 2017/04/14 5:28, Robert Haas wrote:
> On Thu, Apr 6, 2017 at 3:14 AM, Amit Langote
> <Langote_Amit_f8(at)lab(dot)ntt(dot)co(dot)jp> wrote:
>>> 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
>
> OK, whoever wants to write the patch, please step forward.

Sorry, perhaps I'm missing something, but I thought there was no patch
left to be written, because the original patch (this thread) implemented
what Noah recommended.

As of HEAD (6cfaffc0ddc):

create table p (a int, b char) partition by list (a);
create table p1 partition of p for values in (1) partition by list (b);
create table p1a partition of p1 for values in ('a');

\d
List of relations
Schema | Name | Type | Owner
--------+------+-------+-------
public | p | table | amit
public | p1 | table | amit
public | p1a | table | amit
(3 rows)

select tablename from pg_tables where schemaname = 'public';
tablename
-----------
p
p1
p1a
(3 rows)

select table_name from information_schema.tables where table_schema =
'public';
table_name
------------
p
p1
p1a
(3 rows)

Also, it seems that this open item has been listed under Non-bugs, with
remark "firm support for status quo, lack of firm support for alternatives".

Thanks,
Amit