Re: remove unnecessary flag has_null from PartitionBoundInfoData

From: Ashutosh Bapat <ashutosh(dot)bapat(at)enterprisedb(dot)com>
To: amul sul <sulamul(at)gmail(dot)com>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, Jeevan Ladhe <jeevan(dot)ladhe(at)enterprisedb(dot)com>, PostgreSQL Developers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: remove unnecessary flag has_null from PartitionBoundInfoData
Date: 2017-06-12 13:03:00
Message-ID: CAFjFpRdm4kvV6oAKF857_KyQsA4EzN4WipJh_juo2x9OF83AGg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Mon, Jun 12, 2017 at 3:50 PM, amul sul <sulamul(at)gmail(dot)com> wrote:
> On Wed, May 17, 2017 at 10:22 PM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
> [...]
>> I committed this with fixes for those issues, plus I renamed the macro
>> to partition_bound_accepts_nulls, which I think is more clear.
>>
> partition_bound_accepts_nulls() will alway yield true for a range
> partitioning case, because in RelationBuildPartitionDesc, we forgot to
> set boundinfo->null_index to -1.
>
> The attached patch fixes that.
>

Right now, the partition_bound_accepts_nulls() has two callers viz.
check_new_partition_bound() and get_partition_for_tuple(). Both of
those callers are calling it only in case of LIST partition. So,
having null_index uninitialized in PartitionBoundInfoData is not a
problem. But in general, we shouldn't leave a field uninitialized in
that structure, so +1 for the patch.

--
Best Wishes,
Ashutosh Bapat
EnterpriseDB Corporation
The Postgres Database Company

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Masahiko Sawada 2017-06-12 13:47:04 Re: Re: Alter subscription..SET - NOTICE message is coming for table which is already removed
Previous Message Peter Eisentraut 2017-06-12 12:56:58 Re: Re: Alter subscription..SET - NOTICE message is coming for table which is already removed