Skip to content

Conversation

@dey4ss
Copy link
Member

@dey4ss dey4ss commented Jul 29, 2025

@dey4ss dey4ss changed the title Ass+ Support NULLS FIRST and NULLS LAST in ORDER BY clause Jul 29, 2025
Copy link
Collaborator

@Bouncner Bouncner left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good to me.

!SELECT * FROM foo WITH HINT (AVG(another_column));
# ORDER BY with NULL ordering.
!SELECT * FROM students ORDER BY name ASC NULL FIRST;
!SELECT * FROM students ORDER BY name ASC gibberish LAST;
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No additions to queries-good.sql?

Copy link
Member Author

@dey4ss dey4ss Aug 29, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We can only have NULLS FIRST, NULLS LAST, and no specified NULL ordering (with and without sort order). All three cases are covered in the select tests:

TEST(OrderByTest) {
TEST_PARSE_SINGLE_SQL("SELECT grade, city FROM students ORDER BY grade, city DESC NULLS FIRST, name NULLS LAST;",
kStmtSelect, SelectStatement, result, stmt);
ASSERT_NULL(stmt->whereClause);
ASSERT_NOTNULL(stmt->order);
ASSERT_EQ(stmt->order->size(), 3);
ASSERT_EQ(stmt->order->at(0)->type, kOrderAsc);
ASSERT_STREQ(stmt->order->at(0)->expr->name, "grade");
ASSERT_EQ(stmt->order->at(0)->null_ordering, NullOrdering::Undefined);
ASSERT_EQ(stmt->order->at(1)->type, kOrderDesc);
ASSERT_STREQ(stmt->order->at(1)->expr->name, "city");
ASSERT_EQ(stmt->order->at(1)->null_ordering, NullOrdering::First);
ASSERT_EQ(stmt->order->at(2)->type, kOrderAsc);
ASSERT_STREQ(stmt->order->at(2)->expr->name, "name");
ASSERT_EQ(stmt->order->at(2)->null_ordering, NullOrdering::Last);
}

It was not obvious to me which additional cases should be added to queries_good.sql. Do you have something specific in mind?

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Personally, I’d prefer to have good queries just for completes. But you are right, it’s fine as it is.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

a NULLS first, a NULLS last is parsed and needs to be resolved by the user, right?

Copy link
Member Author

@dey4ss dey4ss Sep 1, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Personally, I’d prefer to have good queries just for completes.

I mean, we cannot have all valid SQL queries in this file. I see it more as an extension to cover cases that are not explicitly tested in the more detailed statement tests.

a NULLS first, a NULLS last is parsed and needs to be resolved by the user, right?

It's a valid sort definition and not even contradicting (the same as a ASC, a DESC is fine). It just means we sort first by a with NULLS first and then resolve ties in that ordering by sorting by a with NULLS last (which does not change anything because we only use the second sort definition to compare tuples that have the same value for a). That's not meaningful, but the semantics are perfectly fine and the result is well-defined.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Right, true.

Zündung?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🧨

@dey4ss dey4ss merged commit 0663319 into main Sep 1, 2025
4 checks passed
@dey4ss dey4ss deleted the dey4ss/null_ordering branch September 1, 2025 18:59
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants