Andrew Gierth <andrew@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
