Re: [PATCH] Do not use StdRdOptions in Access Methods - Mailing list pgsql-hackers

From Dent John
Subject Re: [PATCH] Do not use StdRdOptions in Access Methods
Date
Msg-id 2E274E62-4DE4-4168-AAE0-9D287D7C275F@QQdd.eu
Whole thread Raw
In response to Re: [PATCH] Do not use StdRdOptions in Access Methods  (Nikolay Shaplov <dhyan@nataraj.su>)
Responses Re: [PATCH] Do not use StdRdOptions in Access Methods  (Nikolay Shaplov <dhyan@nataraj.su>)
List pgsql-hackers
Hi Nikolay,

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

However, with that change, in the AM’s *options() function, it looks as if you could simply add new fields to the
relopt_parse_eltlist. That’s still not true, because parseRelOptions() will fail to find a matching entry, causing
numoptionsto 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.
Perhapsadd something like this above the tab[]: "When adding or changing a relopt in the relopt_parse_elt tab[], ensure
thecorresponding change is made to boolRelOpts, intRelOpts, realRelOpts or stringRelOpts." 

denty.

> On 6 Oct 2019, at 14:45, Nikolay Shaplov <dhyan@nataraj.su> wrote:
>
> Hi! I am starting a new thread as commitfest wants new thread for new patch.
>
> This new thread is a follow up to an https://www.postgresql.org/message-id/
> 2620882.s52SJui4ql%40x200m thread, where I've been trying to get rid of
> StdRdOpions structure, and now I've splitted the patch into smaller parts.
>
> Read the quote below, to get what this patch is about
>
>> I've been thinking about this patch and came to a conclusion that it
>> would be better to split it to even smaller parts, so they can be
>> easily reviewed, one by one. May be even leaving most complex
>> Heap/Toast part for later.
>>
>> This is first part of this patch. Here we give each Access Method it's
>> own option binary representation instead of StdRdOptions.
>>
>> I think this change is obvious. Because, first, Access Methods do not
>> use most of the values defined in StdRdOptions.
>>
>> Second this patch make Options structure code unified for all core
>> Access Methods. Before some AM used StdRdOptions, some AM used it's own
>> structure, now all AM uses own structures and code is written in the
>> same style, so it would be more easy to update it in future.
>>
>> John Dent, would you join reviewing this part of the patch? I hope it
>> will be more easy now...
>
> And now I have a newer version of the patch, as I forgot to remove
> vacuum_cleanup_index_scale_factor from StdRdOptions as it was used only in
> Btree index and now do not used at all. New version fixes it.
>
> --
> Software Developer: https://www.upwork.com/freelancers/~014a87e140ff02c0da
> Body-oriented Therapist: https://vk.com/nataraj_rebalancing  (Russian)<do-not-use-StdRdOptions-in-AM_2.diff>




pgsql-hackers by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: format of pg_upgrade loadable_libraries warning
Next
From: Tom Lane
Date:
Subject: Re: expressive test macros (was: Report test_atomic_ops() failures consistently, via macros)