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

From Michael Paquier
Subject Re: [PATCH] use separate PartitionedRelOptions structure to storepartitioned table options
Date
Msg-id 20191113073029.GW1549@paquier.xyz
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 store partitioned table options  (Nikolay Shaplov <dhyan@nataraj.su>)
List pgsql-hackers
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.
--
Michael

Attachment

pgsql-hackers by date:

Previous
From: Michael Paquier
Date:
Subject: Re: [PATCH] Do not use StdRdOptions in Access Methods
Next
From: Michael Paquier
Date:
Subject: Re: Coding in WalSndWaitForWal