Andrew Gierth <andrew@tao11.riddles.org.uk> writes:
> "Tom" == Tom Lane <tgl@sss.pgh.pa.us> writes:
> 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.
You missed the "compelling argument why it's needed" part. What is the
need for this? I'm not going to be persuaded by "it was there before".
We've gotten along fine without such inspection functions for FDWs and
tablesample methods, so I doubt that we really need them for index AMs.
Nobody's writing applications that make decisions about which AM to use
based on what they see in pg_am. And anyone who's concerned whether their
AM is reporting the right info is going to be much better served by gdb
than by some functions that can present only a subset of what's in the
info struct.
Moreover, I think you are missing the point about initdb. The issue there
is that anytime in future that we make a change to the AM API, we'd need
to have a debate about whether and how to expose such a change for SQL
inspection. Defining the exposure mechanism as a new function rather than
a new view column changes neither the need for a debate, nor the need for
an initdb unless we decide that we don't need to expose anything. But if
your proposal is merely that we freeze the set of information available
as some subset of what used to be available from pg_am, then it sounds
an awful lot like a backwards-compatibility hack rather than an honest
attempt to describe AM capabilities.
regards, tom lane