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
