Andrew Gierth <and...@tao11.riddles.org.uk> writes:
> "Tom" == Tom Lane <t...@sss.pgh.pa.us> writes:
>  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).

OK, fuzzy thinking on my part --- I was conflating amcanbackward with
whether you can get a descending-order scan.  I can imagine an index
type in which some opclasses can produce btree-ordered output and some
can't, in which case "orderable" has to be per-index and maybe even
per-column.  (If, say, the leading column is orderable and the next
is not, then you could expect to produce output that is sorted by
the first column but not by the first two.)  However, the ability to
back up in a scan is entirely independent of that; see the hash AM,
which sets amcanbackward even though its output has no definable order.

Right offhand it's pretty hard to see how amcanbackward wouldn't be
dependent on AM only.  However, we earlier posited that the only AM-level
properties should be those needed to figure out what you can say in CREATE
INDEX, so if we believe that then can_backward is properly positioned.

>  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?)

No, I don't feel a need to replace that.  But we need to be clear in the
documentation about what this property actually means.  My objection to
having it answer at the index or column level is basically that that
encourages confusion as to what it means.

                        regards, tom lane


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Reply via email to