Can you log a JIRA case please?

For extra credit, the fix would allow the position of nulls to be configurable. 
In CalciteConnectionProperty, add

  enum NullCollation { LOW, HIGH, FIRST, LAST }

and

  DEFAULT_NULL_COLLATION, default HIGH (last for ASC, first for DESC).

The minimum fix is to support HIGH without looking at a config property.

Julian


> On Nov 12, 2015, at 9:19 PM, Li Yang <[email protected]> wrote:
> 
> Sadly no.
> 
> The first example (order by COUNTRY DESC) returns NULL at last, not like
> Oracle's "NULLS FIRST is the default for descending order".
> 
> On Fri, Nov 13, 2015 at 11:40 AM, Julian Hyde <[email protected]> wrote:
> 
>> I don’t know whether we ever spelled out what Calcite’s behavior is. I
>> don’t think the SQL standards specifies, so let’s look to Oracle. The
>> Oracle specification is as follows[1]:
>> 
>>> NULLS LAST is the default for ascending order, and NULLS FIRST is the
>> default for descending order.
>> 
>> Is Calcite consistent with that?
>> 
>> Julian
>> 
>> 
>> 
>> 
>>> On Nov 12, 2015, at 7:30 PM, Li Yang <[email protected]> wrote:
>>> 
>>> Encountered a seemingly inconsistent behavior about NULL in order by.
>> Could
>>> anyone shed some light? (calcite 1.4 release)
>>> 
>>> When a column contains NULL value and order by it desc, the NULL is
>>> positioned at the end of result.
>>> 
>>> E.g.  "select cal_dt, country, ... from xxx order by COUNTRY DESC"
>> returns
>>> 
>>> 2013-08-11 US ....
>>> 2013-08-18 FR  ....
>>> 2013-03-31 null ....
>>> 2013-11-10 null ....
>>> 
>>> However if order by one more column, the NULL will come to the top this
>>> time.
>>> 
>>> E.g.  "select cal_dt, country, ... from xxx order by COUNTRY DESC, CAL_DT
>>> ASC"  returns
>>> 
>>> 2013-03-31 null ....
>>> 2013-11-10 null ....
>>> 2013-08-11 US ....
>>> 2013-08-18 FR  ....
>>> 
>>> I understand NULL's order comparing to other values is vague in SQL,
>> either
>>> putting it first or last is fine. However do expect the order is
>>> consistent. From a user point of view, if it seems NULL is the smallest,
>>> then it should always be so.
>>> 
>>> Thanks
>> 
>> 

Reply via email to