* Andrew Gierth (and...@tao11.riddles.org.uk) wrote: > >>>>> "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?
The capabilities strike me as useful to expose, they're pretty useful to know. I believe we were right to hide the APIs/functions and don't see any need to expose those to the SQL level. > 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. Hmm, that seems pretty reasonable. > That would surely be better than the present condition of being > completely unable to get this information from SQL. Agreed. Thanks! Stephen
signature.asc
Description: Digital signature
