Skip to content

Conversation

hatyo
Copy link
Contributor

@hatyo hatyo commented Oct 2, 2025

This amends a planner sanity check which verifies that only primitive types are allowed when constructing an ordering such that it also accepts UUIDs.

This fixes #3656.

@hatyo hatyo added the bug fix Change that fixes a bug label Oct 2, 2025
requestedOrderingParts.stream()
.allMatch(requestedOrderingPart -> requestedOrderingPart.getValue()
.getResultType().isPrimitive())));
.getResultType().isPrimitive() || requestedOrderingPart.getValue().getResultType().isUuid())));
Copy link
Contributor

Choose a reason for hiding this comment

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

Sorry, I do not agree with this fix. The check makes sure that you never order by something that is not primitive. Isn't a UUID a structure? What happens if I want to order by a UUID column? That should be broken up just like other records should be broken up.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

With #3198 we already added support for UUID as a primitive type in SQL. There is special handling of massaging TupleFieldsProto.UUID messages in the planning and execution codepath (that's what the majority of that PR was about).

Copy link
Collaborator

Choose a reason for hiding this comment

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

Is there a reason that the requestedOrderingPart.getResultType().isPrimitive() doesn't return true if the type is a UUID?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

bug fix Change that fixes a bug

Projects

None yet

Development

Successfully merging this pull request may close these issues.

UUID tests break Debugger sanity checks

3 participants