Re: [HACKERS] fix side-effect in get_qual_for_list() - Mailing list pgsql-hackers

From Ashutosh Bapat
Subject Re: [HACKERS] fix side-effect in get_qual_for_list()
Date
Msg-id CAFjFpRcK=-8iWvBN+zSi+A1_E+Jrndi6X0qeaoyz+QTjacywQQ@mail.gmail.com
Whole thread Raw
In response to [HACKERS] fix side-effect in get_qual_for_list()  (Jeevan Ladhe <jeevan.ladhe@enterprisedb.com>)
Responses Re: [HACKERS] fix side-effect in get_qual_for_list()  (Jeevan Ladhe <jeevan.ladhe@enterprisedb.com>)
List pgsql-hackers
On Thu, May 25, 2017 at 3:12 PM, Jeevan Ladhe
<jeevan.ladhe@enterprisedb.com> wrote:
> Hi,
>
> While working on one of the crash reported on default partition for list
> partitioning table[1] I found some strange behavior in get_qual_for_list()
> while
> I tried to call it from the new code I wrote for default partition.
>
> After debugging, I noticed that the function get_qual_for_list() is
> implicitly
> manipulating the (PartitionBoundSpec) spec->listdatums list. AFAICU, this
> manipulation is needed just to construct a list of datums to be passed to
> ArrayExpr, and this should be done without manipulating the original list.
> The function name is get_qual_for_list(), which implies that this function
> returns something and does not modify anything.
>
> I have made this change in attached patch, as I think this is useful for
> future
> developments, as there may be a need in future to call get_qual_for_list()
> from
> other places, and the caller might not expect that PartitionBoundSpec gets
> modified.
>

Thanks for catching this. For now this isn't a problem since
generate_partition_qual() is crafting PartitionBoundInfo which it
doesn't use anywhere else. But if the function gets used where the
PartitionBoundSpec is being used somewhere else as well. While you are
at it, can we use castNode() in place of
PartitionBoundSpec *spec = (PartitionBoundSpec *) bound; Or do you
think it should be done separately?

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



pgsql-hackers by date:

Previous
From: Petr Jelinek
Date:
Subject: Re: [HACKERS] logical replication - still unstable after all thesemonths
Next
From: Tom Lane
Date:
Subject: Re: [HACKERS] PostgreSQL 10 changes in exclusion constraints - did something change? CASE WHEN behavior oddity