SQLFluff improperly parses unquoted Bigquery project names with dashes

[kdw2126]

Search before asking

• I searched the issues and found no similar issues.

What Happened

Whenever I parse valid BigQuery code which contains my organization's primary project names (which contain dashes), SQLFluff treated the dash as an operator and attempts to apply operator fixes to this code.

Expected Behaviour

I would expect that when an unquoted project name with a dash is clearly being cited as part of a FROM statement, SQLFluff properly understands that the dash is part of a project name and does not apply dash-related operator rules (related to subtraction) to it.

Observed Behaviour

Currently, whenever I use a dashed project name without quoting it, the dash is treated as an operator and spaces are added before and after it (which breaks the SQL code I am working on).

How to reproduce

(1). Generate a new BigQuery SQLFluff project.
(2) Lint the following code with it:

SELECT col_foo
FROM foo-bar.foo.bar

(3). Note that the linter output takes the following form, indicating that the dash is being treated like an operator. This can be reproduced from online.sqlfluff.com

Code	Line / Position	Description
2 / 9	Missing whitespace before -
2 / 9	Missing whitespace after -

Dialect

bigquery

Version

sqlfluff, version 0.10.1
Python 3.8.9
dbt version 1.0.1, although this issue does not involve the dbt templater

Configuration

[sqlfluff]
dialect = bigquery
exclude_rules = L003,L008,L011,L014,L016,L029,L031,L034

[sqlfluff:rules]
max_line_length = 120
comma_style = leading

[sqlfluff:rules:L010]
capitalisation_policy = upper

[sqlfluff:rules:L030]
capitalisation_policy = upper

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

[tunetheweb]

More discussion on this here: #2756 (comment)

These dashes are very much the exception so should ensure we don't allow dashes in other unquoted identifiers.

Table name identifiers have additional syntax to support dashes (-) when referenced in FROM and TABLE clauses.

[tunetheweb]

So turns out we do allow dashses in out BigQuery dialect:

sqlfluff/src/sqlfluff/dialects/dialect_bigquery.py

Lines 809 to 821 in a09b32d

	@bigquery_dialect.segment()
	class HyphenatedObjectReferenceSegment(ObjectReferenceSegment): # type: ignore
	"""A reference to an object that may contain embedded hyphens."""
	type = "hyphenated_object_reference"
	match_grammar = ansi_dialect.get_segment(
	"ObjectReferenceSegment"
	).match_grammar.copy()
	match_grammar.delimiter = OneOf(
	Ref("DotSegment"),
	Sequence(Ref("DotSegment"), Ref("DotSegment")),
	Sequence(Ref("MinusSegment")),
	)

However cause it uses the MinusSegment this is falling foul of L006.

The fix is simple - replicate the MinusSegment but call it something else so L006 doesn't look at it!

PR coming up...