From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
---|---|
To: | Ashutosh Bapat <ashutosh(dot)bapat(at)enterprisedb(dot)com> |
Cc: | amul sul <sulamul(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-13 16:41:19 |
Message-ID: | CA+TgmobOW9w=Fhz36yGy7vm6jv435XK76Z9v1yuiDL7UYvBj-w@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Mon, Jun 12, 2017 at 9:03 AM, Ashutosh Bapat
<ashutosh(dot)bapat(at)enterprisedb(dot)com> wrote:
> 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.
I agree - that's a bug waiting to happen. Committed.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 2017-06-13 16:44:42 | Re: WIP: Data at rest encryption |
Previous Message | Masahiko Sawada | 2017-06-13 16:33:12 | Re: Refreshing subscription relation state inside a transaction block |