From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Peter Eisentraut <peter_e(at)gmx(dot)net> |
Cc: | Stoyan Genov <genov(at)digsys(dot)bg>, Dirk Lutzebaeck <lutzeb(at)aeccom(dot)com>, pgsql-sql(at)postgreSQL(dot)org |
Subject: | Re: [SQL] Howto to force NULL rows at the bottom ? |
Date: | 1999-12-06 00:51:32 |
Message-ID: | 7823.944441492@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-sql |
Peter Eisentraut <peter_e(at)gmx(dot)net> writes:
> Always test everything you say. The NULLs will come out at the end no
> matter which way you order it. There is a TODO item for this, but I
> suspect that the function manager clean up needs to be completed first,
I believe this is not an fmgr issue. The sort comparison routine (in
current sources, comparetup_heap() in backend/utils/sort/tuplesort.c)
checks for nulls before it calls the supplied comparison operator,
and it has a hard-wired decision that NULL sorts after non-NULL.
DESC order doesn't affect this at all (since that just chooses a
different operator).
To my mind, DESC doesn't have anything to do with whether NULLs sort
before or after non-NULLs; if we want a control for that, it should
be something else. It would be pretty easy to drive this off a SET
variable, if you didn't mind having it a global setting rather than
per-query.
The SQL spec seems to leave this up to the implementor:
Whether a sort key value that is null is considered greater
or less than a non-null value is implementation-defined, but
all sort key values that are null shall either be considered
greater than all non-null values or be considered less than
all non-null values.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Hiroshi Inoue | 1999-12-06 02:06:11 | RE: [SQL] Howto to force NULL rows at the bottom ? |
Previous Message | Peter Eisentraut | 1999-12-05 22:56:28 | Re: [SQL] Howto to force NULL rows at the bottom ? |