Re: [HACKERS] remove unnecessary flag has_null from PartitionBoundInfoData
От | Robert Haas |
---|---|
Тема | Re: [HACKERS] remove unnecessary flag has_null from PartitionBoundInfoData |
Дата | |
Msg-id | CA+TgmobOW9w=Fhz36yGy7vm6jv435XK76Z9v1yuiDL7UYvBj-w@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: [HACKERS] remove unnecessary flag has_null from PartitionBoundInfoData (Ashutosh Bapat <ashutosh.bapat@enterprisedb.com>) |
Список | pgsql-hackers |
On Mon, Jun 12, 2017 at 9:03 AM, Ashutosh Bapat <ashutosh.bapat@enterprisedb.com> wrote: > On Mon, Jun 12, 2017 at 3:50 PM, amul sul <sulamul@gmail.com> wrote: >> On Wed, May 17, 2017 at 10:22 PM, Robert Haas <robertmhaas@gmail.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
В списке pgsql-hackers по дате отправления: