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

Hi Alvaro,

On Wed, Nov 13, 2019 at 6:55 AM Alvaro Herrera <alvherre@2ndquadrant.com> wrote:
> On 2019-Nov-07, Amit Langote wrote:
> > On Tue, Nov 5, 2019 at 9:22 AM Michael Paquier <michael@paquier.xyz> wrote:
> > >  Please note that I have not switched the old interface
> > > to be static to reloptions.c as if you look closely at reloptions.h we
> > > allow much more flexibility around HANDLE_INT_RELOPTION to fill and
> > > parse the reloptions in custom AM.  AM maintainers had better use the
> > > new interface, but there could be a point for more customized error
> > > messages.
> >
> > I looked around but don't understand why these macros need to be
> > exposed.  I read this comment:
> >
> >  *  Note that this is more or less the same that fillRelOptions does, so only
> >  *  use this if you need to do something non-standard within some option's
> >  *  code block.
> >
> > but don't see how an AM author might be able to do something
> > non-standard with this interface.
> >
> > Maybe Alvaro knows this better.
>
> I think the idea was that you could have external code doing things in a
> different way for some reason, ie. not use a bytea varlena struct that
> could be filled by fillRelOptions but instead ... do something else.
> That's why those macros are exposed.  Now, this idea doesn't seem to be
> aged very well.  Maybe exposing that stuff is unnecessary.

Thanks for chiming in about that.  I guess that means that we don't
need those macros, except GET_STRING_RELOPTION_LEN() that's used in
allocateReloptStruct(), which can be moved to reloptions.c.  Is that
correct?

Thanks,
Amit