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 20191112045003.GJ1549@paquier.xyz
Whole thread Raw
In response to Re: [PATCH] use separate PartitionedRelOptions structure to store partitioned table options  (Nikolay Shaplov <dhyan@nataraj.su>)
Responses Re: [PATCH] use separate PartitionedRelOptions structure to storepartitioned table options  (Michael Paquier <michael@paquier.xyz>)
List pgsql-hackers
On Mon, Nov 11, 2019 at 05:22:32PM +0300, Nikolay Shaplov wrote:
> Here goes v3 patch with the typo fixed

Still one here in v3 of the patch:
+   * Since there are no options for patitioned tables for now, we just do
+   * validation to report incorrect option error and leave.
It looks like you are having a hard time with partitioned tables.

+  if (validate)
+       parseRelOptions(reloptions, validate, RELOPT_KIND_PARTITIONED,
+                       &numoptions);
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.
--
Michael

Attachment

pgsql-hackers by date:

Previous
From: "imai.yoshikazu@fujitsu.com"
Date:
Subject: RE: Planning counters in pg_stat_statements (using pgss_store)
Next
From: Michael Paquier
Date:
Subject: Re: Add SQL function to show total block numbers in the relation