Robert Haas <robertmhaas@gmail.com> writes:
> On Thu, Aug 11, 2016 at 11:35 AM, Tom Lane <tgl@sss.pgh.pa.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
possiblefrom SQL. We've addressed that by adding a facility for the index AM to perform such checks instead. (Much
morecould be done in that line, but for now we're content if the amvalidate functions more or less replace what
opr_sanityused 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