Re: Adding support for Default partition in partitioning

> I will work on a fix and send a patch shortly.
>
>
Attached is the V28 patch that fixes the issue reported by Rajkumar.
The patch series is exactly same as that of V27 series[1].
The fix is in patch 0002, and macro partition_bound_has_default() is
again moved in 0002 from 0003, as the fix needed to use it.

The fix is basically in get_partition_for_tuple() as below:

@@ -1973,30 +2209,46 @@ get_partition_for_tuple(PartitionDispatch *pd,

if (key->strategy == PARTITION_STRATEGY_RANGE)
{
- /*
- * Since we cannot route tuples with NULL partition keys
through a
- * range-partitioned table, simply return that no partition
exists
- */
for (i = 0; i < key->partnatts; i++)
{
if (isnull[i])
{
- *failed_at = parent;
- *failed_slot = slot;
- result = -1;
- goto error_exit;
+ /*
+ * We cannot route tuples with NULL partition keys
through
+ * a range-partitioned table if it does not have a
default
+ * partition. In such case simply return that no
partition
+ * exists for routing null partition key.
+ */
+ if (!partition_bound_has_default(partdesc->boundinfo))
+ {
+ *failed_at = parent;
+ *failed_slot = slot;
+ result = -1;
+ goto error_exit;
+ }
+ else
+ {
+ /*
+ * If there is any null partition key, it would be
+ * routed to the default partition.
+ */
+ range_partkey_has_null = true;
+ break;
+ }
}
}
}

/*
- * A null partition key is only acceptable if null-accepting list
- * partition exists.
+ * If partition strategy is LIST and this is a null partition key,
+ * route it to the null-accepting partition. Otherwise, route by
+ * searching the array of partition bounds.
*/
cur_index = -1;
- if (isnull[0] && partition_bound_accepts_nulls(partdesc->boundinfo))
+ if (key->strategy == PARTITION_STRATEGY_LIST && isnull[0] &&
+ partition_bound_accepts_nulls(partdesc->boundinfo))
cur_index = partdesc->boundinfo->null_index;
- else if (!isnull[0])
+ else if (!range_partkey_has_null && !isnull[0])
{

The fix would be much easier if the refactoring patch 0001 by Amul in hash
partitioning thread[2] is committed.
The current code mixes the routing for list and range partitioning, and
makes
it difficult to understand and fix any issues coming forward. I believe it
will
be a good idea to keep the logic separate for both partitioning strategies.
Thoughts, view?

[1]
https://www.postgresql.org/message-id/CAAJ_b96jnnjsVCcMG5tpiDLLi8B76dK%2BR2wermmk6uKbOnwdFg%40mail.gmail.com
[2]
https://www.postgresql.org/message-id/CAAJ_b96jnnjsVCcMG5tpiDLLi8B76dK%2BR2wermmk6uKbOnwdFg%40mail.gmail.com

Regards,
Jeevan Ladhe