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

>>>>> "Tom" == Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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_backward
Tom> 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 index
Tom> or column properties. That seems a bit silly: whether or not the
Tom> AM can do multi columns, a specific index is what it is. I'd be a
Tom> bit inclined to have those 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 applying
Tom> can_unique at the index or column level. Is that supposed to mean
Tom> 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)