Teodor Sigaev <[EMAIL PROTECTED]> writes: >> but the real problem is that there's no way for the planner >> to reason about ordering in this representation. This patch would >> guarantee that an ORDER BY with the NULLS option couldn't use an >> indexscan, even if the index sorts nulls at the correct end.
> Patch is smart enough about "native" NULL's ordering, so it adds quals > only if it needed. [ looks again... ] Oh, so you've hard-wired the assumption that ASC/DESC correlate to NULLS FIRST/LAST right into the grammar :-( This is not a workable base for future extension. To be able to do anything interesting with descending-order opclasses, we really have to separate ASC/DESC from NULLS FIRST/LAST, not bind them permanently together. BTW, another sufficient reason to reject this approach is that a query entered as "ORDER BY foo NULLS FIRST" would come out as something quite different, if reverse-listed by ruleutils.c. We've paid the price of that sort of shortsightedness too many times in the past: implementation details should not get exposed in the reverse-listing. As a rule of thumb, if you are putting a transformation involving semantic knowledge into gram.y, you are probably putting it in the wrong place. (One of the reasons I like the typmod patch is that it helps pull a lot of inappropriate knowledge out of gram.y ...) regards, tom lane ---------------------------(end of broadcast)--------------------------- TIP 6: explain analyze is your friend