oracle: bare "/" in CREATE VIEW ... AS SELECT misparsed as SQL*Plus slash-buffer-executor (regression in 4.3.0)

Search before asking

• I searched the issues and found no similar issues.

What Happened

While upgrading from 4.2.0 to 4.3.0, we found what looked like an ST03 false positive, but tracing it back, the real defect is in the parser: a bare (unparenthesized) / division operator in the SELECT/WHERE of a CREATE VIEW ... AS SELECT ... statement (Oracle dialect) gets misparsed as the SQL*Plus slash-buffer-executor. Everything after it collapses into one opaque unparsable section, so any rule needing structure past that point, ST03 in our case; misbehaves as a downstream symptom. This is not every use of /: wrapping it in parens, or having it already sit inside a function call's parens, avoids it. Measured against our ~2,900 SQL files: 64 of 685 CREATE VIEW files containing a / are actually affected.

Examples: where sample_time > sysdate - 1/24 → breaks (bare, unparenthesized division) where sample_time > sysdate - (1/24) → parses fine (wrapped in parens) round(write.value / 1024 / 1024) as write_mb → parses fine (the whole division sits inside round(...)'s own parens) nvl(bytes, 0) / 1024 / 1024 as size_mb → breaks (the nvl(...) call only wraps its own arguments, the / 1024 / 1024 trailing it is still bare/unparenthesized at the top level)

Expected Behaviour

/ inside CREATE VIEW ... AS SELECT ... should parse as division, same as CREATE TABLE ... AS SELECT and same as it did in 4.2.0.

Observed Behaviour

A bare / is consumed as slash_buffer_executor; the same division wrapped in parens parses fine.

How to reproduce

Three conditions required, removing any one fixes it:

1. Statement is CREATE VIEW ... AS SELECT ... (CREATE TABLE ... AS SELECT is fine).
2. SELECT/WHERE contains /.
3. That / is not already inside parens (its own or a function call's).

repro.sql as

CREATE VIEW myview AS
select 1 / 100 as z from dual;

sqlfluff parse --dialect oracle repro.sql Result: PRS | Found unparsable section: '100 as z from dual;'. Expected: clean parse.

Isolation notes: CREATE TABLE ... AS SELECT unaffected; +/-/* unaffected; bare WITH ... SELECT (no CREATE VIEW) unaffected; literal vs. column operand doesn't matter.

Dialect

oracle

Version

Introduced in 4.3.0. Confirmed clean in 4.2.0

Configuration

No project-specific configuration needed; a bare --dialect oracle on the CLI reproduces it:

pip install sqlfluff==4.3.0 sqlfluff lint --dialect oracle --rules ST03 repro.sql

Are you willing to work on and submit a PR to address the issue?

• Yes I am willing to submit a PR!

Code of Conduct

• I agree to follow this project's Code of Conduct