>>>>> "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:


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

 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:

Reply via email to