From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Peter Eisentraut <peter_e(at)gmx(dot)net> |
Cc: | Rene Pijlman <rene(at)lab(dot)applinet(dot)nl>, pgsql-hackers(at)postgresql(dot)org, pgsql-jdbc(at)postgresql(dot)org |
Subject: | Re: [JDBC] NULLs and sort order |
Date: | 2001-09-16 05:12:23 |
Message-ID: | 16765.1000617143@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers pgsql-jdbc |
Peter Eisentraut <peter_e(at)gmx(dot)net> writes:
> Rene Pijlman writes:
>> Currently the JDBC driver says:
>> - Backend >= 7.2 sorts nulls higher than any other value in a
>> domain. In other words: ascending means nulls at the end,
>> descending means nulls at the start.
>> - Backend < 7.2 puts nulls at the end regardless of sort order.
> That is correct.
Actually it's more complex than that. 7.2 will provide the above-stated
consistent ordering of nulls relative to non-nulls. The problem with
earlier versions is that the ordering of nulls depends on what plan the
optimizer chooses for the query: sorting based on a scan of a btree
index would work the same as is described for 7.2, whereas sorting
based on an explicit sort step would put the nulls at the end (for
either ASC or DESC sort). So there was *no* consistent behavior at all
in prior versions. The fix that's been applied for 7.2 is to make
explicit sorts act the same as indexscans already did.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2001-09-16 05:22:35 | Re: Warning about oid/xid wraparound |
Previous Message | Bruce Momjian | 2001-09-16 05:05:07 | Re: Warning about oid/xid wraparound |
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 2001-09-16 19:35:35 | Re: UpdateableResultSet patch (not finished yet!) |
Previous Message | Rene Pijlman | 2001-09-15 19:43:58 | Re: isNullable() |