On 2018-Jul-23, Pavel Stehule wrote:
> p.s. Another patch can be replacement of relation type from "table" to
> "partitioned table"
>
> postgres=# \dt+
> List of relations
> +--------+------------+-------------------+-------+---------+-------------+
> | Schema | Name | Type | Owner | Size | Description |
> +--------+------------+-------------------+-------+---------+-------------+
> | public | data | partitioned table | pavel | 0 bytes | |
> | public | data_2016 | table | pavel | 15 MB | |
> | public | data_2017 | table | pavel | 15 MB | |
> | public | data_other | table | pavel | 11 MB | |
> +--------+------------+-------------------+-------+---------+-------------+
> (4 rows)
I think this is a clear improvement. The term "table" was introduced
for this case by f0e44751d7 ("Implement table partitioning.") and now
the author of that commit supports this change. I used the term "index"
for partitioned indexes originally because I was copying the existing
term, but now I too think they should say "partitioned indexes" instead,
because they are different enough objects from plain indexes.
To be certain I'm not going against some old decision, I digged up
Amit's old patches. Turns out he submitted psql's describe.c using the
term "partitioned table" on August 10th [1] and then based on a
discussion where Robert suggested calling these new objects "partition
roots" instead to avoid confusion, it was changed to "table" in the next
submission on August 26th [2]. It seems the right call to have used the
term "table" in many places (rather than "partition roots"), but at
least in psql's \dt it seems extremely useful to show the type as
"partitioned table" instead, because it is one place where the
distinction is clearly useful.
In this thread there have been no contrary votes, so I'm pushing this
part soon.
[1] https://postgr.es/m/ad16e2f5-fc7c-cc2d-333a-88d4aa446f96@lab.ntt.co.jp
[2] https://postgr.es/m/169708f6-6e5a-18d1-707b-1b323e4a6baf@lab.ntt.co.jp
--
Álvaro Herrera https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services