Re: [HACKERS] dropping partitioned tables without CASCADE

Поиск
Список
Период
Сортировка
От Rushabh Lathia
Тема Re: [HACKERS] dropping partitioned tables without CASCADE
Дата
Msg-id CAGPqQf1iuASO2P3DnWMF510Nw8vbkubfM8tq5sAteSwohZbkHg@mail.gmail.com
обсуждение исходный текст
Ответ на Re: [HACKERS] dropping partitioned tables without CASCADE  (Ashutosh Bapat <ashutosh.bapat@enterprisedb.com>)
Ответы Re: [HACKERS] dropping partitioned tables without CASCADE  (Ashutosh Bapat <ashutosh.bapat@enterprisedb.com>)
Список pgsql-hackers
I picked this patch for review and started looking at the implementation details.

Consider the below test:

1)

postgres=# create table foo (a int, b int) partition by list (a);
CREATE TABLE
postgres=# \d foo
                Table "public.foo"
 Column |  Type   | Collation | Nullable | Default
--------+---------+-----------+----------+---------
 a      | integer |           |          |
 b      | integer |           |          |
Partition key: LIST (a)
Number of partitions: 0

postgres=# \d+ foo
                                    Table "public.foo"
 Column |  Type   | Collation | Nullable | Default | Storage | Stats target | Description
--------+---------+-----------+----------+---------+---------+--------------+-------------
 a      | integer |           |          |         | plain   |              |
 b      | integer |           |          |         | plain   |              |
Partition key: LIST (a)
Number of partitions: 0

In the above case, verbose as well as normal output give information
about number of partitions.

2) Add partition to the foo;

create table foo_p1 partition of foo for values in (1, 2, 3) partition by list (b);

postgres=# \d foo
                Table "public.foo"
 Column |  Type   | Collation | Nullable | Default
--------+---------+-----------+----------+---------
 a      | integer |           |          |
 b      | integer |           |          |
Partition key: LIST (a)
Number of partitions: 1 (Use \d+ to list them.)

postgres=# \d+ foo
                                    Table "public.foo"
 Column |  Type   | Collation | Nullable | Default | Storage | Stats target | Description
--------+---------+-----------+----------+---------+---------+--------------+-------------
 a      | integer |           |          |         | plain   |              |
 b      | integer |           |          |         | plain   |              |
Partition key: LIST (a)
Partitions: foo_p1 FOR VALUES IN (1, 2, 3) has partitions

Above verbose output for foo says, foo_p1 "has partitions". But if I do

postgres=# \d foo_p1
               Table "public.foo_p1"
 Column |  Type   | Collation | Nullable | Default
--------+---------+-----------+----------+---------
 a      | integer |           |          |
 b      | integer |           |          |
Partition of: foo FOR VALUES IN (1, 2, 3)
Partition key: LIST (b)
Number of partitions: 0

it tell "Number of partitions: 0".

I feel like information is conflicting with each other. AFAIU, idea about adding
"has partitions" was to let know that it's a partitioned table. So can you directly
add the "is partitioned" in place of "has partitions"?

Did those change in the attached patch and update regression expected output.

Also run pgindent on the patch.

Thanks,



On Mon, Sep 4, 2017 at 6:22 PM, Ashutosh Bapat <ashutosh.bapat@enterprisedb.com> wrote:
On Mon, Sep 4, 2017 at 3:48 PM, Alvaro Herrera <alvherre@alvh.no-ip.org> wrote:
>
>                         if (tuples > 0)
>                         {
> -                               if (tableinfo.relkind != RELKIND_PARTITIONED_TABLE)
> -                                       printfPQExpBuffer(&buf, _("Number of child tables: %d (Use \\d+ to list them.)"), tuples);
> -                               else
> -                                       printfPQExpBuffer(&buf, _("Number of partitions: %d (Use \\d+ to list them.)"), tuples);
> +                               printfPQExpBuffer(&buf, _("Number of %s: %d (Use \\d+ to list them.)"), ct, tuples);
>                                 printTableAddFooter(&cont, buf.data);
>                         }
>
> Please don't do this, because it breaks translatability.  I think the
> original is fine.
>

We have used this style in the "else" case of if (!verbose). So, I
just copied it. I have removed that change in the attached patch.

--
Best Wishes,
Ashutosh Bapat
EnterpriseDB Corporation
The Postgres Database Company


--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers




...
Rushabh Lathia
Вложения

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Michael Paquier
Дата:
Сообщение: Re: [HACKERS] CLUSTER command progress monitor
Следующее
От: Michael Paquier
Дата:
Сообщение: Re: [HACKERS] document and use SPI_result_code_string()