>>>>> "Tom" == Tom Lane <t...@sss.pgh.pa.us> writes:
>> With the gutting of pg_am in 9.6, there seems to be no longer any >> way for a query of the system catalogs to discover any of the index >> capabilities that were formerly columns in pg_am (notably >> amcanorder, amcanorderbyop, amclusterable, amsearcharray, >> amsearchnulls). >> Am I missing something or is this a significant oversight? Tom> It's absolutely not an oversight. We asked when 65c5fcd35 went in Tom> whether there was still any need for that information to be Tom> available at the SQL level, and nobody appeared to care. Perhaps you were asking the wrong people? Tom> We could in theory expose a view to show the data --- but since a Tom> large part of the point of that change was to not need initdb for Tom> AM API changes, and to not be constrained to exactly Tom> SQL-compatible representations within that API, I'm disinclined to Tom> do so without a fairly compelling argument why it's needed. 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. That would surely be better than the present condition of being completely unable to get this information from SQL. -- 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
