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

From Jeevan Ladhe
Subject Re: [HACKERS] fix side-effect in get_qual_for_list()
Date
Msg-id CAOgcT0Pqo+xcft5yGaAYEm2-V6tf8kry_tgKA2AbOfadrnY4Dg@mail.gmail.com
Whole thread Raw
In response to Re: [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()  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
Hi,

I have rebased the patch on recent commit.

With recent commits, some of the hunks in the v2 patch related to
castNode, are not needed.

PFA.

Regards,
Jeevan Ladhe

On Sat, May 27, 2017 at 1:16 AM, Jeevan Ladhe <jeevan.ladhe@enterprisedb.com> wrote:
Hi Ashutosh,

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.

Yes, this behavior currently does not affect adversely, but I think this
function is quite useful for future enhancements and should be fixed.

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?

I have made this change at couple of places applicable.

PFA.

Regards,
Jeevan Ladhe 

Attachment

pgsql-hackers by date:

Previous
From: Amit Kapila
Date:
Subject: Re: [HACKERS] pg_resetwal is broken if run from v10 against olderversion of PG data directory
Next
From: Petr Jelinek
Date:
Subject: Re: [HACKERS] logical replication - still unstable after all thesemonths