Re: [PATCH] use separate PartitionedRelOptions structure to store partitioned table options - Mailing list pgsql-hackers

From Nikolay Shaplov
Subject Re: [PATCH] use separate PartitionedRelOptions structure to store partitioned table options
Date
Msg-id 1657573.lyga8ggrqq@x200m
Whole thread Raw
In response to Re: [PATCH] use separate PartitionedRelOptions structure to storepartitioned table options  (Michael Paquier <michael@paquier.xyz>)
Responses Re: [PATCH] use separate PartitionedRelOptions structure to storepartitioned table options
List pgsql-hackers
В письме от среда, 13 ноября 2019 г. 16:30:29 MSK пользователь Michael Paquier
написал:
> On Tue, Nov 12, 2019 at 01:50:03PM +0900, Michael Paquier wrote:
> > We have been through great length to have build_reloptions, so
> > wouldn't it be better to also have this code path do so?  Sure you
> > need to pass NULL for the parsing table..  But there is a point to
> > reduce the code paths using directly parseRelOptions() and the
> > follow-up, expected calls to allocate and to fill in the set of
> > reloptions.
>
> So I have been looking at this one, and finished with the attached.
> It looks much better to use build_reloptions() IMO, taking advantage
> of the same sanity checks present for the other relkinds.
Thanks!

I did not read that thread yet, when I sent v3 patch.
build_reloptions is a good stuff and we should use it for sure.

I've looked at yours v4 version of the patch, it is exactly what we need here.
Can we commit it as it is?


--
Software Developer: https://www.upwork.com/freelancers/~014a87e140ff02c0da
Body-oriented Therapist: https://vk.com/nataraj_rebalancing  (Russian)



pgsql-hackers by date:

Previous
From: Asif Rehman
Date:
Subject: Re: WIP/PoC for parallel backup
Next
From: Tom Lane
Date:
Subject: Re: checking my understanding of TupleDesc