Andrew Gierth <and...@tao11.riddles.org.uk> writes: > This table shows what properties are exposed at the AM-wide level, the > per-index level and the per-column level.
+1 mostly, but I'm a bit bemused by can_order and can_backward having different scopes --- how come? Also, not sure about allowing things like can_multi_col as index or column properties. That seems a bit silly: whether or not the AM can do multi columns, a specific index is what it is. I'd be a bit inclined to have those return null except at the AM level. In particular, I'm not sure what you intend to mean by applying can_unique at the index or column level. Is that supposed to mean that the index or column *is* unique? If so, I'd prefer a different name for that, on the same principle that "orderable" is not the same thing as "can_order". > distance_orderable now returns true/false depending on the opclass, not > just on the amcanorderbyop field. In order to do this, I've added an > optional amproperty function to the AM api, which if it exists, gets > first dibs on all property calls so it can override the result as it > sees fit. Hmm, seems like for that case, it'd be easier to look into pg_amop and see if the opclass has any suitably-marked operators. The AMs that support this would have to duplicate such code anyway, so it seems better to just have one copy. Or we could leave it to the client to do that join, which is the sort of approach that Stephen was advocating anyway, IIUC. Adding an AM override method might be a good idea anyway, but I'm not convinced that it's an appropriate way to address this particular point. regards, tom lane -- Sent via pgsql-hackers mailing list (email@example.com) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers