>>>>> "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:

Reply via email to