Re: No longer possible to query catalogs for index capabilities?

>>>>> "Tom" == Tom Lane <tgl@sss.pgh.pa.us> writes:
>> This table shows what properties are exposed at the AM-wide level,>> the per-index level and the per-column level.
Tom> +1 mostly, but I'm a bit bemused by can_order and can_backwardTom> having different scopes --- how come?

That's where they were in the previous list, a couple of messages up in
the thread...

Currently can_backward is always the same for all indexes in the same
AM, but I guess there's no guarantee that won't change. In the previous
message you suggested it might have to be per-column, even, but I think
that makes no sense (either the whole index is scannable in both
directions or it is not, it can't be different per column).
Tom> Also, not sure about allowing things like can_multi_col as indexTom> or column properties.  That seems a bit
silly:whether or not theTom> AM can do multi columns, a specific index is what it is.  I'd be aTom> bit inclined to
havethose return null except at the AM level.
 

I thought it would be cleaner to be able to query all properties at the
most specific level.
Tom> In particular, I'm not sure what you intend to mean by applyingTom> can_unique at the index or column level.  Is
thatsupposed to meanTom> that the index or column *is* unique?
 

No. (We could add properties like is_unique, is_exclusion which clients
currently query in pg_index; should we?)

-- 
Andrew (irc:RhodiumToad)