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

From Nikolay Shaplov
Subject [PATCH] use separate PartitionedRelOptions structure to store partitioned table options
Date
Msg-id 1627387.Qykg9O6zpu@x200m
Whole thread Raw
Responses Re: [PATCH] use separate PartitionedRelOptions structure to storepartitioned table options
Re: [PATCH] use separate PartitionedRelOptions structure to storepartitioned table options
List pgsql-hackers
Hi!

This message is follow up to the "Get rid of the StdRdOptions" patch thread:
https://www.postgresql.org/message-id/2620882.s52SJui4ql@x200m

I've split patch into even smaller parts and commitfest want each patch in 
separate thread. So it is new thread.

The idea of this patch is following: If you read the code, partitioned tables 
do not have any options (you will not find RELOPT_KIND_PARTITIONED in 
boolRelOpts, intRelOpts, realRelOpts, stringRelOpts and enumRelOpts in 
reloption.c), but it uses StdRdOptions to store them (these no options).

If partitioned table is to have it's own option set (even if it is empty now) 
it would be better to save it into separate structure, like it is done for 
Views, not adding them to StdRdOptions, like current code hints to do.

So in this patch I am creating a structure that would store partitioned table 
options (it is empty for now as there are no options for this relation kind), 
and all other code that would use this structure as soon as the first option 
comes.

I think it is bad idea to suggest option adder to ad it to StdRdOption, we 
already have a big mess there. Better if he add it to an new empty structure.

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

pgsql-hackers by date:

Previous
From: Amit Kapila
Date:
Subject: Re: [HACKERS] Block level parallel vacuum
Next
From: Nikolay Shaplov
Date:
Subject: Re: [PATCH] Do not use StdRdOptions in Access Methods