Re: [HACKERS] Partitions: \d vs \d+

Поиск
Список
Период
Сортировка
От Maksim Milyutin
Тема Re: [HACKERS] Partitions: \d vs \d+
Дата
Msg-id 77f6ff29-a0ed-58c5-10aa-d504d9e40765@gmail.com
обсуждение исходный текст
Ответ на Re: [HACKERS] Partitions: \d vs \d+  (Amit Langote <Langote_Amit_f8@lab.ntt.co.jp>)
Список pgsql-hackers

On 29.09.2017 04:33, Amit Langote wrote:

So, we should be looking at partconstraintdef only when verbose is true,
because that's only when we set it to a valid value.  Now, if
partconstraintdef is NULL even after verbose is true, that means backend
returned that there exists no constraint for that partition, which I
thought would be true for a default partition (because the commit that
introduced default partitions also introduced "No partition constraint"),
but it's really not.

For example, \d and \d+ show contradictory outputs for a default partition.

create table p (a int) partition by list (a);
create table p1 partition of p for values in (1);
create table pd partition of p default;

\d pd                Table "public.pd"Column |  Type   | Collation | Nullable | Default
--------+---------+-----------+----------+---------a      | integer |           |          |
Partition of: p DEFAULT
No partition constraint

\d+ pd                                   Table "public.pd"Column |  Type   | Collation | Nullable | Default | Storage | Stats
target | Description
--------+---------+-----------+----------+---------+---------+--------------+-------------a      | integer |           |          |         | plain   |              |
Partition of: p DEFAULT
Partition constraint: (NOT ((a IS NOT NULL) AND (a = ANY (ARRAY[1]))))


Perhaps, there is no case when "No partition constraint" should be output,
but I may be missing something.

Anyhow, we have to protect ourselves from empty output from pg_get_partition_constraintdef. And printing No partition constraint would be good point to start to examine why we didn't get any constraint definition.
-- 
Regards,
Maksim Milyutin

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

Предыдущее
От: tushar
Дата:
Сообщение: Re: [HACKERS] SendRowDescriptionMessage() is slow for queries with alot of columns
Следующее
От: Konstantin Knizhnik
Дата:
Сообщение: Re: [HACKERS] pg_prepared_xact_status