> I am not sure how we can resolve this. btree cannot easily work
> differently than it does --- we could make either choice for where nulls
> appear in the index, but once we've done that we have no real choice
> about what ORDER BY on the index will do, in either direction. So
> it seems that we really do need to make nulls sort differently in
> ASC and DESC sorts. But the explicit-sort routine has no idea whether
> ASC or DESC is involved ... indeed can't, because we may have a
> "USING operator" clause in there and no ASC or DESC anywhere. Shall
> explicit-sort try to guess whether the operator it's given represents
> the fore or aft direction of a btree index? The operator might not be
> one that is btree-indexable at all, so I don't see how that can work.
We are pretty cheezy about using > and < for ORDER BY. Any chance to
look up the actual comparison symbol from the cache and do something
based on "<" or ">"? Do we have a pg_operator oid or something else
there? If it is not one of those, we can just order them
however we want to.
-- Bruce Momjian | http://www.op.net/~candle maillist@candle.pha.pa.us | (610)
853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill,
Pennsylvania19026