On Thu, Aug 11, 2016 at 11:35 AM, Tom Lane <t...@sss.pgh.pa.us> wrote: > Robert Haas <robertmh...@gmail.com> writes: >> On Wed, Aug 10, 2016 at 6:14 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: >>> In short, I do not see a good reason to expose ampredlocks at the SQL >>> level, and I think there needs to be a darn good reason to expose any of >>> this stuff, not just "maybe some DBA will think he needs to query this". > >> I don't think you're being unreasonable, but I don't agree with your >> approach. I think that we should expose everything we reasonably can, >> and if we have to change it later then it will be a backward >> compatibility break. Making it unqueryable in the hopes that people >> won't try to query it is futile. > > 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; when that turned out to be false, you argued that they could hard-code the index types instead of querying for capabilities; when there was opposition to that, you fell back to your present position of arguing that only the smallest possible subset of it should be made queryable. This is basically the same argument we have every time somebody wants to remove a "static" from a function prototype or stick a PGDLLIMPORT on a variable. 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. I don't expect this post or any other to convince you that such a view is in fact sensible, but I could hope that at some point you might be willing to admit that it's widely-held. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (firstname.lastname@example.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers