Do we need SQL-level access to amoptions functions?

There is some text in indexam.sgml currently that says

[ index AMs' amoptions functions ] should be correctly
declared as taking <type>text[]</> and <type>bool</> and returning
<type>bytea</>. This provision allows client code to execute
<function>amoptions</> to test validity of options settings.

In the pending AM interface rewrite, amoptions has been changed to a C API
which means it's not accessible from SQL. So if there's anything out
there that is actually relying on being able to call, eg, ginoptions()
from SQL, it's gonna be broken.

Does anyone know of client code that's actually doing this?

If we do want to continue supporting this type of thing, we could invent
a new function, say validate_amoptions(amname text, options text[])
that would look up and call the correct amoptions function. This would be
much easier to use from SQL anyway; right now you could only do it, for an
arbitrary AM, with a series of two queries with the function name obtained
from the first query being inserted into the second one. Ugh. (The lack
of complaints about this suggests nobody is doing it.)

I'm not planning to hold off committing the interface rewrite because of
this, but if anyone wants to preserve this functionality, they should
think about writing such a function in time for 9.6.

regards, tom lane