Horton

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

Amit Langote <amitlangote09@gmail.com>

View thread View on postgr.es
From: Amit Langote <amitlangote09@gmail.com>
To: Nikolay Shaplov <dhyan@nataraj.su>
Cc: Michael Paquier <michael@paquier.xyz>, Tomas Vondra <tomas.vondra@2ndquadrant.com>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>, 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-10-10T05:58:50Z
Lists: pgsql-hackers 
Hello,

On Tue, Oct 8, 2019 at 7:50 PM Nikolay Shaplov <dhyan@nataraj.su> wrote:
> В письме от вторник, 8 октября 2019 г. 16:00:49 MSK пользователь Amit Langote
> написал:
> > IIUC, this patch invents PartitionedRelOptions as the binary
> > representation for future RELOPT_KIND_PARTITIONED parameters.  As long
> > as others are on board with using different *Options structs for
> > different object kinds, I see no problem with this idea.
> Yes, this is correct. Some Access Methods already use it's own Options
> structure. As far as I can guess StdRdOptions still exists only for historical
> reasons, and became quite a mess because of adding all kind of stuff there.
> Better to separate it.
>
> BTW, as far as you are familiar with this part of the code, may be you will
> join the review if this particular patch?

Sure, I will try to check your patch.

Thanks,
Amit

Commits

  1. Split handling of reloptions for partitioned tables