Hi Alvaro, On Wed, Nov 13, 2019 at 6:55 AM Alvaro Herrera <alvhe...@2ndquadrant.com> wrote: > On 2019-Nov-07, Amit Langote wrote: > > On Tue, Nov 5, 2019 at 9:22 AM Michael Paquier <mich...@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
