[HACKERS] fix hard-coded index in make_partition_op_expr

Поиск
Список
Период
Сортировка
От Jeevan Ladhe
Тема [HACKERS] fix hard-coded index in make_partition_op_expr
Дата
Msg-id CAOgcT0M6-mx+dSX47JGJuJP1CKr4XssBFVmKNETt0OZYWpFr+w@mail.gmail.com
обсуждение исходный текст
Ответы Re: [HACKERS] fix hard-coded index in make_partition_op_expr  (Robert Haas <robertmhaas@gmail.com>)
Список pgsql-hackers
Hi,

While browsing through the partitioning code, I noticed that a recent commit
f8bffe9e6d700fd34759a92e47930ce9ba7dcbd5, which fixes multi-column range
partitioning constraints, introduced a function make_partition_op_expr, that
takes keynum as a input parameter to identify the index of the partition key.
In case of range partition we can have multiple partition keys but for list
partition we have only one. Considering that, I think following code does not
cause any side-effect logically(and may be a oversight while moving the code
from function get_qual_for_list to this function):

saopexpr->inputcollid = key->partcollation[0];
saopexpr->args = list_make2(arg1, arg2);

But as we have keynum now, should we be using it to index key->partcollation,
instead of a hard coded '0'.

I tried to look around in list partitioning and hard coded '0' is used at all
the places, but that code is either list specific or does not have availability
of partitioned key index.

Attached patch does this small change in make_partition_op_expr.
Another way is to, have an Assert in case of PARTITION_STRATEGY_LIST:
Assert(keynum != 0);

PFA.

Regards,
Jeevan Ladhe
Вложения

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

Предыдущее
От: Jeevan Ladhe
Дата:
Сообщение: Re: [HACKERS] Adding support for Default partition in partitioning
Следующее
От: Amit Kapila
Дата:
Сообщение: Re: [HACKERS] UPDATE of partition key