Re: No longer possible to query catalogs for index capabilities?

Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> On Thu, Aug 11, 2016 at 11:35 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> Well, if it's unqueryable they won't be able to query it no matter how
>> hard they try ;-).

> Sure, but as this thread already demonstrates, they may also complain
> forcefully about having lost that capability. You argued when
> removing the pg_am columns that nobody cared about the ability to
> query any of them;

Sir, that's just historical revisionism. I/we asked at the time whether
people needed any of that info, and heard nothing but crickets. It was
mentioned multiple times during the development thread, see for example
https://www.postgresql.org/message-id/17342.1439225415%40sss.pgh.pa.us
or
https://www.postgresql.org/message-id/19218.1440604259%40sss.pgh.pa.us
or even the commit message in question (65c5fcd35):

A disadvantage is that SQL-level code can no longer see attributes
of index AMs; in particular, some of the crosschecks in the opr_sanity
regression test are no longer possible from SQL. We've addressed that
by adding a facility for the index AM to perform such checks instead.
(Much more could be done in that line, but for now we're content if the
amvalidate functions more or less replace what opr_sanity used to do.)
We might also want to expose some sort of reporting functionality, but
this patch doesn't do that.

I will admit that I'd rather minimize than maximize the amount of
information we expose here, but I think that's an entirely defensible
position.

> ... You argue against
> these things on the grounds that they might change later, but the
> overwhelming evidence from posts on this list is that people would
> prefer to have access to APIs that might not be stable rather than
> have no access at all.

That doesn't stop them from bitching when we do change things they
were depending on. I'm fine with exposing things there is a clear
use-case for, but I do not see that there is a reasonable use-case
for exposing ampredlocks.

regards, tom lane