Robert Haas <robertmh...@gmail.com> writes: > On Thu, Aug 11, 2016 at 11:35 AM, Tom Lane <t...@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 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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
