Re: No longer possible to query catalogs for index capabilities? - Mailing list pgsql-hackers

On Wed, Aug 10, 2016 at 6:14 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Kevin Grittner <kgrittn@gmail.com> writes:
>> That one seems like it should either be at the AM level or not
>> included at all.  Where it would be interesting to know is if you
>> are a hacker looking for an AM to enhance with support, or (when
>> there is more than just btree supported, so it is not so easy to
>> remember) if you are a DBA investigating a high rate of
>> serialization failures and want to know whether indexes of a
>> certain type have index-relation predicate locking granularity or
>> something more fine-grained.  The latter use case seems plausible
>> once there is more of a mix of support among the AMs.
>
> TBH, that line of thought impresses me not at all, because I do not see
> a reason for SQL queries to need to see internal behaviors of AMs, and
> especially not at levels as crude as boolean properties of entire AMs,
> because that's just about guaranteed to become a lie (or at least not
> enough of the truth) in a year or two.  If you are a DBA wanting to know
> how fine-grained the locking is in a particular index type, you really
> need to read the source code or ask a hacker.
>
> We have been bit by the "representation not good enough to describe actual
> behavior" problem *repeatedly* over the years that pg_am had all this
> detail.  First it was amstrategies and amsupport, which have never
> usefully described the set of valid proc/op strategy numbers for any index
> type more complicated than btree.  Then there was amorderstrategy, which
> we got rid of in favor of amcanorder, and later added amcanbackward to
> that (not to mention amcanorderbyop).  And amconcurrent, which went away
> for reasons I don't recall.  Then we added amstorage, which later had to
> be supplemented with amkeytype, and still isn't a very accurate guide to
> what's actually in an index.  amcanreturn actually was a boolean rather
> than a function for awhile (though it looks like we never shipped a
> release with that definition).  There's still a lot of stuff with
> obviously limited life expectancy, like amoptionalkey, which is at best a
> really crude guide to what are valid index qualifications; someday that
> will likely have to go away in favor of a "check proposed index qual for
> supportability" AM callback.
>
> So I don't think I'm being unreasonable in wanting to minimize, not
> maximize, the amount of info exposed through this interface.  There is
> enough history to make me pretty sure that a lot of things that might be
> simple boolean properties today are going to be less simple tomorrow, and
> then we'll be stuck having to invent arbitrary definitions for what the
> property-test function is going to return for those.  And if there are
> any queries out there that are depending on simplistic interpretations
> of those property flags, they'll be broken in some respect no matter
> what we do.
>
> In short, I do not see a good reason to expose ampredlocks at the SQL
> level, and I think there needs to be a darn good reason to expose any of
> this stuff, not just "maybe some DBA will think he needs to query this".

I don't think you're being unreasonable, but I don't agree with your
approach.  I think that we should expose everything we reasonably can,
and if we have to change it later then it will be a backward
compatibility break.  Making it unqueryable in the hopes that people
won't try to query it is futile.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company