DELETE command includes duplicate whitespace

[sgoll]

Setup

Versions

• Rust: 1.83.0
• Diesel: 2.2.6
• Database: SQLite
• Operating System Linux

Feature Flags

• diesel: r2d2, returning_clauses_for_sqlite_3_35, sqlite, uuid

Problem Description

SQL queries generated for DELETE commands include an unnecessary duplicate space between DELETE and FROM. This can be seen from emitting the corresponding strings in walk_ast():

diesel/diesel/src/query_builder/delete_statement/mod.rs

Lines 261 to 267 in b705023

	fn walk_ast<'b>(&'b self, mut out: AstPass<'_, 'b, DB>) -> QueryResult<()> {
	out.push_sql("DELETE ");
	self.from_clause.walk_ast(out.reborrow())?;
	self.where_clause.walk_ast(out.reborrow())?;
	self.returning.walk_ast(out.reborrow())?;
	Ok(())
	}

The trailing space can safely be omitted here because self.from_clause.walk_ast() always contributes a leading space itself, leading to duplication, in its own walk_ast() method:

diesel/diesel/src/query_builder/from_clause.rs

Lines 128 to 131 in b705023

	fn walk_ast<'b>(&'b self, mut pass: AstPass<'_, 'b, DB>) -> QueryResult<()> {
	pass.push_sql(" FROM ");
	self.from_clause.walk_ast(pass)
	}

Since DELETE  is always followed by  FROM —self.from_clause is not optional and must always be emitted—, the trailing space is not necessary, similar to how INSERT commands are prepared without trailing space (because they are always followed by  INTO ):

diesel/diesel/src/query_builder/insert_statement/mod.rs

Lines 488 to 491 in b705023

	fn walk_ast<'b>(&'b self, mut out: AstPass<'_, 'b, DB>) -> QueryResult<()> {
	out.push_sql("INSERT");
	Ok(())
	}

What are you trying to accomplish?

Issue clean, beautiful SQL queries.

What is the expected output?

DELETE FROM "table"

What is the actual output?

DELETE FROM "table"

Are you seeing any additional errors?

No.

Steps to reproduce

Issue a DELETE query as in the following code:

let num_deleted = diesel::delete(posts.filter(title.like(pattern)))
    .execute(connection)
    .expect("Error deleting posts");

Checklist

• I have already looked over the issue tracker and the discussion forum for similar possible closed issues.

• This issue can be reproduced on Rust's stable channel. (Your issue will be
  closed if this is not the case)
• This issue can be reproduced without requiring a third party crate