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.
--
Álvaro Herrera https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
