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

From: Nikolay Shaplov <dhyan(at)nataraj(dot)su>
To: Amit Langote <amitlangote09(at)gmail(dot)com>
Cc: Michael Paquier <michael(at)paquier(dot)xyz>, Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Dent John <denty(at)qqdd(dot)eu>, "Iwata, Aya" <iwata(dot)aya(at)jp(dot)fujitsu(dot)com>, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, Dmitry Dolgov <9erthalion6(at)gmail(dot)com>, Thomas Munro <thomas(dot)munro(at)gmail(dot)com>
Subject: Re: [PATCH] use separate PartitionedRelOptions structure to store partitioned table options
Date: 2019-10-08 10:50:23
Message-ID: 14150373.LTX8QO94hs@x200m
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

В письме от вторник, 8 октября 2019 г. 16:00:49 MSK пользователь Amit Langote
написал:

> > > > 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).
> > >
> > > I am not even sure that we actually need that. What kind of reloption
> > > you would think would suit into this subset?
> >
> > Actually I do not know. But the author of partitioned patch, added a stub
> > for partitioned tables to have some reloptions in future. But this stub
> > is designed to use StdRdOptions. Which is not correct, as I presume. So
> > here I am correcting the stub.
>
> I wrote the patch that introduced RELOPT_KIND_PARTITIONED. Yes, it
> was added as a stub relopt_kind to eventually apply to reloptions that
> could be sensibly applied to partitioned tables. We never got around
> to working on making the existing reloptions relevant to partitioned
> tables, nor did we add any new partitioned table-specific reloptions,
> so it remained an unused relopt_kind.
Thank you for clarifying thing.

> 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?

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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Marius Timmer 2019-10-08 11:15:57 Re: ICU for global collation
Previous Message Nikolay Shaplov 2019-10-08 10:44:25 Re: [PATCH] Add some useful asserts into View Options macroses