Formatted SQL adds spaces inside the next string literal after a string ending in a backslash

オープン
  • 何か問題がありますか？
#6,500 コメント 2 件 リアクション 0 件 担当者 0 名 GitHub で見る

メンテナーはふだん 3 日以内に返信

まだ誰も着手していません。

  • #6507 @ayushdoesdev による — マージされずにクローズ

評価

難易度
4/5
見積もり時間
1〜2日
初心者へのやさしさ
38/100
issue の種類
バグ
明瞭さ
明確に書かれている
活発さ
活発
技術スタック
rust, sql
領域
backend, databases

調査の方向性

Start in prqlc/prqlc/src/sql/mod.rs at sql::compile and trace how generated SQL is passed to sqlformat::format; inspect the sqlformat tokenizer behavior described in the issue. Compare the proposed options and add a regression test for the backslash-ending string example. Done means formatted output preserves the literal value; the issue leaves the interim approach and upstream report for maintainers to decide.

索引モデルが issue の本文から書いたものです。

説明

bug

When a string literal in the query ends with a backslash, the formatted SQL (the default output) changes the value of the next string literal by adding spaces inside its quotes. The query then compares against, or selects, a different string than the one written. --no-format output is correct.

prql target:sql.postgres
from files
filter path == 'C:\\' || name == 'readme'

prqlc compile --no-format, which is correct:

SELECT * FROM files WHERE path = 'C:\' OR name = 'readme'

prqlc compile:

SELECT
  *
FROM
  files
WHERE
  path = 'C:\' OR name = ' readme '

name = ' readme ' matches no row that name = 'readme' would. The same happens with derive {a = 'ab\\', b = 'c'}, which emits ' c ' AS b, and with raw strings like r'x\'. Any string whose value ends in a backslash triggers it; the query doesn't have to be unusual.

Cause: sql::compile passes the SQL that sqlparser generates through sqlformat::format. The sqlformat 0.5.0 tokenizer (get_string_token in src/tokenizer.rs) always treats a backslash as an escape inside '...' and "...". So it reads 'C:\' as an unterminated string that runs on to the next '. The quotes then pair up wrongly, and the formatter adds spaces around tokens that are really inside string literals. In standard SQL, and in the Postgres, DuckDB, SQLite and generic dialects PRQL targets, a backslash is an ordinary character, so 'C:\' is a complete literal. FormatOptions::dialect (Generic / PostgreSql / SQLServer) doesn't change this, and 0.5.0 is the latest sqlformat release. I found no report of this in shssoichiro/sqlformat-rs.

Why this is an issue rather than a PR: the durable fix is upstream, in sqlformat's tokenizer, perhaps keyed on its dialect. Any interim change in prqlc is a trade-off a maintainer should pick:

  • Skip formatting, and return the unformatted SQL, when the generated SQL contains a backslash. This is simple and can't corrupt values, but those queries lose their layout.
  • Mask string literals before formatting and restore them afterwards. This keeps the layout, but adds a second tokenizer pass in prqlc.

Either change would come with a regression test like the example above. Filing the upstream report would also need a decision: the repo shows no agent-contribution policy, so per this repo's tend guidance it waits for a go-ahead here.

主要言語
Rust
スター
10.9k
フォーク
261
平均マージ
3日 21時間
マージ済み PR（30日）
84

環境構築

Codespaces で開く

このプロジェクトの開発コンテナを、あなたの GitHub アカウントでブラウザ上に起動します。

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

PRQL/prql のほかの issue

PRQL/prql の issue をすべて見る

似ている issue

Rust の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。