Re: No longer possible to query catalogs for index capabilities?

>>>>> "Tom" == Tom Lane <tgl@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.  WhatTom> is the need for this?  I'm not going to be
persuadedby "it wasTom> 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 FDWsTom> 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 AMTom> 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.  TheTom> issue there is that anytime in future that we
makea change to theTom> AM API, we'd need to have a debate about whether and how to exposeTom> such a change for SQL
inspection. Defining the exposure mechanismTom> as a new function rather than a new view column changes neitherTom> the
needfor a debate, nor the need for an initdb unless we decideTom> 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)