>>>>> "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
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?)
Sent via pgsql-hackers mailing list (firstname.lastname@example.org)
To make changes to your subscription: