Re: Default Partition for Range

From: Beena Emerson <memissemerson(at)gmail(dot)com>
To: Jeevan Ladhe <jeevan(dot)ladhe(at)enterprisedb(dot)com>
Cc: Ashutosh Bapat <ashutosh(dot)bapat(at)enterprisedb(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Default Partition for Range
Date: 2017-05-30 06:43:33
Message-ID: CAOG9ApGcXsieMUd-4oC8So_GvOrgF-w+GcsdffP-7b0T_Qo=5g@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Mon, May 29, 2017 at 3:22 PM, Jeevan Ladhe
<jeevan(dot)ladhe(at)enterprisedb(dot)com> wrote:
> Hi Beena,
>
> I went through your patch, and here are some of my comments:
>

Thank you for your comments. I will take care of them in the next
version of patch.

> - I am sorry, but I could not understand following hunk. Does this change
> really
> belongs to this patch? If not, it will be better to handle it separately.
>
> @@ -2242,33 +2387,16 @@ get_partition_for_tuple(PartitionDispatch *pd,
> ecxt->ecxt_scantuple = slot;
> FormPartitionKeyDatum(parent, slot, estate, values, isnull);
>
> - if (key->strategy == PARTITION_STRATEGY_RANGE)
> + if (key->strategy == PARTITION_STRATEGY_LIST && isnull[0])
> {
> /*
> - * Since we cannot route tuples with NULL partition keys through
> - * a range-partitioned table, simply return that no partition
> - * exists
> + * A null partition key is only acceptable if null-accepting list
> + * partition exists.
> */

In RANGE, initially NULL was not allowed, now NULL is routed to
default. I have only removed the check for null in RANGE and kept the
check for null partition in case of list.

--

Beena Emerson

EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Dilip Kumar 2017-05-30 06:45:31 Re: POC: Sharing record typmods between backends
Previous Message Konstantin Knizhnik 2017-05-30 06:30:10 Re: Surjective functional indexes