#559 made the engine refuse a reserved word where a regular identifier goes, which is what ISO/IEC 39075:2024 subclause 21.3 asks for. The list is generated from the grammar artifact, so it is the standard's answer and not one this repository chose, and it is long: the direct list plus the pre-reserved forty.
The consequence lands in the client repositories rather than here. A test query written before #559 could say RETURN count(p) AS count or declare a property called number, and it parsed. After the pin moves it does not, and the failure arrives as a syntax error in a test that has nothing to do with the change that moved the pin. That happened twice this month, on zu-go and zu-python, and both took a while to read because the error names a position rather than the rule.
The twelve that actually bit, all confirmed against crates/zu-common/src/keywords/generated.rs: on, at, number, nothing, record, small, count, big, day, exact, sum, next. Most of them read like ordinary column names, which is why they were written.
Swept the other three and they are clean: zu-node, zu-java and zu-c name nothing after a reserved word. zu-go was fixed in tamnd/zu-go#26 and zu-python alongside it.
What is missing is a way to ask. A client author writing a test has no cheap check for whether a name they picked is reserved, short of running it. Two things would help and neither is large:
- The refusal could say which rule it is.
42001: nothing may follow RETURN, found string literal is what a caller sees for one of these, and it is a position rather than a reason. A condition that says the word is reserved, and which of the two lists it came from, is a message that fixes itself. is_pre_reserved already exists for exactly this and nothing calls it.
- The list could be reachable from a client. It is generated into a Rust static that is
pub(super), so nothing outside the crate can read it. A published copy, either over the C ABI or as a file in the repository that the clients already vendor, turns this from a thing you learn by breaking into a thing you look up.
Neither is a blocker for anything. Filing it because the same failure has now cost two afternoons and will cost a third.
#559 made the engine refuse a reserved word where a regular identifier goes, which is what ISO/IEC 39075:2024 subclause 21.3 asks for. The list is generated from the grammar artifact, so it is the standard's answer and not one this repository chose, and it is long: the direct list plus the pre-reserved forty.
The consequence lands in the client repositories rather than here. A test query written before #559 could say
RETURN count(p) AS countor declare a property callednumber, and it parsed. After the pin moves it does not, and the failure arrives as a syntax error in a test that has nothing to do with the change that moved the pin. That happened twice this month, on zu-go and zu-python, and both took a while to read because the error names a position rather than the rule.The twelve that actually bit, all confirmed against
crates/zu-common/src/keywords/generated.rs:on,at,number,nothing,record,small,count,big,day,exact,sum,next. Most of them read like ordinary column names, which is why they were written.Swept the other three and they are clean: zu-node, zu-java and zu-c name nothing after a reserved word. zu-go was fixed in tamnd/zu-go#26 and zu-python alongside it.
What is missing is a way to ask. A client author writing a test has no cheap check for whether a name they picked is reserved, short of running it. Two things would help and neither is large:
42001: nothing may follow RETURN, found string literalis what a caller sees for one of these, and it is a position rather than a reason. A condition that says the word is reserved, and which of the two lists it came from, is a message that fixes itself.is_pre_reservedalready exists for exactly this and nothing calls it.pub(super), so nothing outside the crate can read it. A published copy, either over the C ABI or as a file in the repository that the clients already vendor, turns this from a thing you learn by breaking into a thing you look up.Neither is a blocker for anything. Filing it because the same failure has now cost two afternoons and will cost a third.