At 12/10/2000 01:17 AM (Sunday), Claudio via sourceforge.net wrote:

>Details: Hello. According to the standard, it's up to the db vendor where
>NULLs should be, either at the tail or at the head of an ordered
>recordset. In IB, when you order ASC (default) on a field with NULLs, they
>go to the tail. That's a vendor decision. However, the engine must be
>consistent and in this case, it doesn't: if you order DESC on the same
>fields, NULLs will appear at the tail, too. One of the answers should be
>changed.

This enhancement request came through the sourceforge bug tracking system
today. Remembering that NULL is not a value but a state, I'm not so sure
this proposal is the right answer.

I think you could make a case for having NULLs always trail the non-NULL
values in a result set, regardless of the requested sort order of the
result set. While I can see the logic of thinking of NULL as a value which
has a collation order, I can also see the logic of treating them as "and we
also have these records which were produced but they don't quite fit in so
we are sending them along at the end".

Anyway, I thought it might bear some examination in the architect list.