RE: Found an example prooving bug

> From my point of view, NULL is neither bigger, nor smaller, you can't
> compare it with a number.
> So it just comes at the end if you sort at all.
Well, I know you can't compare null in, for example, WHERE clause. But if
we want to sort data in some way, I would like Postgres to behave in any,
but predictable, way. If last of the query execution steps is sorting,
null values are always at the end. And it would be OK, but, depending on
the query, values in database, and some options (like ENABLE_SORT),
null-values are sometimes at the beginning, because it uses order stored
in index.
Also, for my bug-report Tom Lane replied with some details from SQL92
specs. And my last mail, with an example (I can wrote less complex
one) shows, that pgsql doesn't work the way SQL92 says. So, is it
compliant with SQL92 standard in this matter or is it not? If it's not,
shouldn't that be changed?
> (Perhaps you need to take a think about what NULL means in your data. Should
> NULL sort as if it's 0?, +infinity?, -infinity? if so why?)
As I wrote - any way. But fixed one.
To finish this problem - I've changed my program to use -infinity for null
values (but I really don't like it :) ). I still think pgsql is not
compliant with SQL92, but I'm not the one to decide if it should be
changed.

Best regards

Marcin Zukowski