>>>>> "Tom" == Tom Lane <t...@sss.pgh.pa.us> writes:
>> It could easily be exposed as a function interface of the form >> index_has_capability(oid,name) or indexam_has_capability(oid,name) >> without any initdb worries. Tom> You missed the "compelling argument why it's needed" part. What Tom> is the need for this? I'm not going to be persuaded by "it was Tom> there before". How about "it was there before, and people did use it"? In fact I notice you participated in a discussion of this a couple of months back on the JDBC list, in which your solution was to suggest hardcoding the name 'btree' into the query: https://www.postgresql.org/message-id/24504.1463237368%40sss.pgh.pa.us Doesn't that strike you as an indication that something is wrong? Tom> We've gotten along fine without such inspection functions for FDWs Tom> and tablesample methods, which are new and not especially interesting to code doing introspection Tom> so I doubt that we really need them for index AMs. People write catalog queries for indexes a whole lot more than they do for FDWs or tablesample methods. This whole discussion started because I wrote a catalog query for someone on IRC, and found I couldn't do it on 9.6 because amcanorder was gone. Tom> Nobody's writing applications that make decisions about which AM Tom> to use based on what they see in pg_am. That's not the issue. The issue is finding information about _existing_ indexes that is not otherwise exposed. Tom> Moreover, I think you are missing the point about initdb. The Tom> issue there is that anytime in future that we make a change to the Tom> AM API, we'd need to have a debate about whether and how to expose Tom> such a change for SQL inspection. Defining the exposure mechanism Tom> as a new function rather than a new view column changes neither Tom> the need for a debate, nor the need for an initdb unless we decide Tom> that we don't need to expose anything. I'm not proposing a new function for each capability. I'm proposing ONE function (or two, one starting from the index rather than the AM, for convenience). Adding more capability names would not require an initdb. -- Andrew (irc:RhodiumToad) -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
