Skip to content

compare bug in temporary tables #64

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
tomas-villagesql merged 1 commit into from
Feb 26, 2026
Merged

compare bug in temporary tables #64

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
8 changes: 8 additions & 0 deletions storage/temptable/include/temptable/cell_calculator.h
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -291,6 +291,14 @@ inline int Cell_calculator::compare(const Cell &lhs, const Cell &rhs) const {
/* Note: Using if-s instead of switch due to bug mentioned in hash(). */

if (m_mode == Mode::BINARY) {
// VillageSQL: cell data is raw (no length prefix), so call
// TryCompareCustomType directly instead of key_cmp which expects a
// 2-byte length-prefixed key image.
auto result = villagesql::TryCompareCustomType(
m_mysql_field, lhs_data, lhs_data_length, rhs_data, rhs_data_length);
if (result.has_value()) {
return result.value();
}
return const_cast<Field *>(m_mysql_field)->key_cmp(lhs_data, rhs_data);
Copy link
Copy Markdown
Member

@malone-at-work malone-at-work Feb 26, 2026

Choose a reason for hiding this comment

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

So the call WAS going through sql/field.cc Line 6757, which was trying to use the length prefix. But if it is NOT a custom type, it is doing the same thing below on Line 6764. Why is that not problematic? Do we have a different representation than other varstring?

Copy link
Copy Markdown
Member Author

@tomas-villagesql tomas-villagesql Feb 26, 2026

Choose a reason for hiding this comment

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

I don't follow

Copy link
Copy Markdown
Member

@malone-at-work malone-at-work Feb 26, 2026

Choose a reason for hiding this comment

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

We had a discussion offline, it is because we aren't using an encoding, which is not something that other binary varchars would use. I am not sure if there is a simplification, that would get rid of these special cases, but let's unblock for now.

} else if (m_mode == Mode::CHARSET) {
lhs_length = lhs_data_length;
Expand Down
2 changes: 2 additions & 0 deletions villagesql/examples/vsql-complex/src/complex.cc
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -28,6 +28,7 @@

#include <villagesql/extension.h>

#include <cassert>
#include <cmath>
#include <cstddef>
#include <cstdint>
Expand Down Expand Up @@ -180,6 +181,7 @@ bool decode_complex(const unsigned char *buffer, size_t buffer_size, char *to,
int cmp_complex(const unsigned char *data1, size_t len1,
const unsigned char *data2, size_t len2) {
if (len1 < kComplexSize || len2 < kComplexSize) {
assert(len1 != 0);
Copy link
Copy Markdown
Member

@villagestevers villagestevers Feb 26, 2026

Choose a reason for hiding this comment

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

Do we want this, or len1 != kComplexSize and len2 as well?

Copy link
Copy Markdown
Member

@malone-at-work malone-at-work Feb 26, 2026

Choose a reason for hiding this comment

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

I replace this assert in a follow up PR, with a warning, so I don't think it is worth changing here.

return 0; // Invalid lengths, treat as equal
}

Expand Down