Horton

Re: [PATCH] use separate PartitionedRelOptions structure to store partitioned table options

Michael Paquier <michael@paquier.xyz>

View thread View on postgr.es
From: Michael Paquier <michael@paquier.xyz>
To: Nikolay Shaplov <dhyan@nataraj.su>
Cc: pgsql-hackers@lists.postgresql.org, Amit Langote <amitlangote09@gmail.com>, Tomas Vondra <tomas.vondra@2ndquadrant.com>, Dent John <denty@qqdd.eu>, "Iwata, Aya" <iwata.aya@jp.fujitsu.com>, Alvaro Herrera <alvherre@2ndquadrant.com>, Dmitry Dolgov <9erthalion6@gmail.com>, Thomas Munro <thomas.munro@gmail.com>
Date: 2019-11-13T07:30:29Z
Lists: pgsql-hackers

Attachments

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

Commits

  1. Split handling of reloptions for partitioned tables