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

>>>>> "Tom" == Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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)