| 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: | Whole Thread | Raw Message | 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 ? |