Re: [PATCH] Do not use StdRdOptions in Access Methods

From: Nikolay Shaplov <dhyan(at)nataraj(dot)su>
To: Dent John <denty(at)qqdd(dot)eu>
Cc: Thomas Munro <thomas(dot)munro(at)gmail(dot)com>, Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, "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>, Michael Paquier <michael(at)paquier(dot)xyz>
Subject: Re: [PATCH] Do not use StdRdOptions in Access Methods
Date: 2019-10-08 10:33:34
Message-ID: 39264708.TaejMXGD49@x200m
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

В письме от понедельник, 7 октября 2019 г. 18:55:20 MSK пользователь Dent John
написал:

> I like the new approach. And I agree with the ambition — to split out the
> representation from StdRdOptions.
Thanks.

> However, with that change, in the AM’s *options() function, it looks as if
> you could simply add new fields to the relopt_parse_elt list. That’s still
> not true, because parseRelOptions() will fail to find a matching entry,
> causing numoptions to be left zero, and an early exit made. (At least,
> that’s if I correctly understand how things work.)
>
> I think that is fine as an interim limitation, because your change has not
> yet fully broken the connection to the boolRelOpts, intRelOpts, realRelOpts
> and stringRelOpts strutures. But perhaps a comment would help to make it
> clear. Perhaps add something like this above the tab[]: "When adding or
> changing a relopt in the relopt_parse_elt tab[], ensure the corresponding
> change is made to boolRelOpts, intRelOpts, realRelOpts or stringRelOpts."
Whoa-whoa!

I am not inventing something new here. Same code is already used in brin
(brin.c:820), gin (ginutils.c:602) and gist (gistutils.c:909) indexes. I've
just copied the idea, to do all index code uniform.

This does not mean that these code can't be improved, but as far as I can
guess it is better to do it in small steps, first make option code uniform, and
then improve all of it this way or another...

So I here I would suggest to discuss it I copied this code correctly, without
going very deeply into discussion how we can improve code I've used as a
source for cloning.

And then I have ideas how to do it better. But this will come later...

--
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 Antonin Houska 2019-10-08 10:34:23 Re: Transparent Data Encryption (TDE) and encrypted files
Previous Message Amit Kapila 2019-10-08 10:09:17 Re: Proposal: Make use of C99 designated initialisers for nulls/values arrays