>>>>> "Tom" == Tom Lane <t...@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_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) -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
