Re: any way for ORDER BY x to imply NULLS FIRST in 8.3?

Simon Riggs wrote:
> On Wed, 2007-11-07 at 16:05 +0100, Martijn van Oosterhout wrote:
>> On Wed, Nov 07, 2007 at 02:37:41PM +0000, Simon Riggs wrote:
>>> Editing an application, you would be required to add the words NULLS
>>> FIRST to every single ORDER BY and every single CREATE INDEX in an
>>> application. If we know that is what people would do, why not have one
>>> parameter to do this for them?
>> I find it hard to beleive that every single query in an application
>> depends on the ordering of NULLs. In fact, I don't think I've even
>> written a query that depended on a particular way of sorting NULLs. Is
>> it really that big a deal?
>
> True, but how would you know for certain? You'd need to examine each
> query to be able to tell, which would take even longer. Or would you not
> bother, catch a few errors in test and then wait for the application to
> break in random ways when a NULL is added later? I guess that's what
> most people do, if they do convert.
>
> I'd like to remove one difficult barrier to Postgres adoption. We just
> need some opinions from people who *havent* converted to Postgres, which
> I admit is difficult cos they're not listening.
>

May I, as an outsider, comment? :) I really think of ASC NULLS FIRST
(and DESC NULLS LAST) as the way to go. Imagine a last_login column that
sorts users that have not logged in as the most recently logged in,
which is not very intuitive. I vote for sort_nulls_first defaulting to
false in order not to break bc.