On Thu, Aug 11, 2016 at 11:35 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Robert Haas <robertmhaas@gmail.com> writes:
>> On Wed, Aug 10, 2016 at 6:14 PM, Tom Lane <tgl@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
