Inconsistent double-quoted identifier semantics between HTTP SQL and MySQL protocol

[discord9]

What type of bug is this?

Incorrect result, User Experience

What subsystems are affected?

Frontend, Query Engine, Write Protocols

Minimal reproduce step

Run logically equivalent SQL through the HTTP SQL API and through the MySQL protocol/client, using double quotes for identifiers.

For example, HTTP/UI SQL commonly accepts PostgreSQL-style quoted identifiers:

SELECT *
FROM k8s_resources."kube_pod_container_resource_limits_cpu_cores:sum"
WHERE "namespace" >= 'y'
ORDER BY "greptime_timestamp" DESC
LIMIT 1;

Then run the same or similar SQL through a MySQL client/protocol connection:

SELECT *
FROM k8s_resources."kube_pod_container_resource_limits_cpu_cores:sum"
WHERE namespace >= 'y'
ORDER BY "greptime_timestamp" DESC
LIMIT 1;

In the MySQL dialect/protocol, double quotes may be parsed as string literals unless ANSI_QUOTES-style behavior is enabled. As a result, ORDER BY "greptime_timestamp" can be planned as ordering by a constant string, e.g. Utf8("greptime_timestamp"), rather than ordering by the greptime_timestamp column.

This is easy to hit when users copy SQL from HTTP/UI output or examples into a MySQL client.

What did you expect to see?

The same SQL text should not silently change semantics across GreptimeDB protocols without an obvious warning/error.

Possible acceptable behaviors:

• MySQL protocol supports/documented ANSI_QUOTES behavior for double-quoted identifiers;
• or MySQL protocol rejects/warns on suspicious double-quoted identifiers like "greptime_timestamp" when they look like column names;
• or documentation clearly states that MySQL clients must use backticks or unquoted identifiers, for example:

ORDER BY `greptime_timestamp` DESC
WHERE `namespace` >= 'y'

What did you see instead?

The HTTP SQL interface and MySQL protocol can interpret double quotes differently:

• HTTP SQL: "greptime_timestamp" is treated as an identifier.
• MySQL protocol/client: "greptime_timestamp" can be treated as a string literal.

This can silently produce a different logical/physical plan. In the observed case, the MySQL plan sorted by a constant Utf8("greptime_timestamp") instead of the timestamp column. That changes optimizer behavior for ORDER BY ... LIMIT, TopK, dynamic filters, and scan planning, and is very misleading during performance investigation.

What operating system did you use?

Linux x86_64

What version of GreptimeDB did you use?

Observed against a GreptimeDB server reporting 8.4.2 GreptimeDB via MySQL protocol.

Relevant log output and stack trace

Relevant plan symptom from MySQL protocol investigation:

ORDER BY "greptime_timestamp" was planned as sorting by a constant Utf8("greptime_timestamp") instead of column greptime_timestamp.

The issue is not limited to this specific table/query; it is a protocol/dialect consistency and UX problem.

[discord9]

Related prior discussion: #3530 covered the same underlying protocol quote-scheme mismatch for Dashboard/HTTP SHOW CREATE TABLE output copied into MySQL client.

This issue focuses on a runtime query case where the SQL can still execute but silently changes semantics/plan shape, for example:

ORDER BY "greptime_timestamp" DESC

being interpreted under MySQL protocol as sorting by a string literal/constant instead of the greptime_timestamp column.

[killme2008]

I don’t think this is an issue, as we support different dialects for different protocols:

• GreptimeDB (HTTP): backticks and double-quoted identifiers
• MySQL: backticks
• PostgreSQL: double-quoted identifiers

We render identifiers in double quotes for HTTP and PostgreSQL protocols.

Users should be aware of these differences, and the dashboard could include a feature to select the appropriate dialect.