fix hard-coded index in make_partition_op_expr

From: Jeevan Ladhe <jeevan(dot)ladhe(at)enterprisedb(dot)com>
To: PostgreSQL Developers <pgsql-hackers(at)postgresql(dot)org>
Subject: fix hard-coded index in make_partition_op_expr
Date: 2017-05-17 09:38:26
Message-ID: CAOgcT0M6-mx+dSX47JGJuJP1CKr4XssBFVmKNETt0OZYWpFr+w@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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

Attachment Content-Type Size
fix_indexing_make_partition_op_expr_v1.patch application/octet-stream 554 bytes

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Amit Kapila 2017-05-17 09:45:07 Re: UPDATE of partition key
Previous Message Jeevan Ladhe 2017-05-17 09:29:31 Re: Adding support for Default partition in partitioning