Teodor Sigaev <teodor@sigaev.ru> 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
