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

Đang mở
  • Có gì không ổn?
#6,500 2 bình luận 0 reaction 0 người được giao Xem trên GitHub

Maintainer thường phản hồi trong vòng 3 ngày

Chưa có ai nhận issue này.

  • #6507 của @ayushdoesdev — đã đóng, không merge

Đánh giá

Độ khó
4/5
Thời gian dự kiến
1-2 ngày
Mức phù hợp với người mới
38/100
Loại issue
Lỗi
Độ rõ ràng
Đặc tả rõ ràng
Mức độ hoạt động
Sôi nổi
Công nghệ
rust, sql
Lĩnh vực
backend, databases

Hướng nghiên cứu

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.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.

Mô tả

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.

Ngôn ngữ chính
Rust
Star
10.9k
Fork
261
Merge trung bình
3 ngày 21 giờ
Pull request đã merge (30 ngày)
84

Chuẩn bị môi trường

Mở trong Codespaces

Khởi chạy dev container của dự án ngay trên trình duyệt, bằng tài khoản GitHub của bạn.

Bắt đầu từ đâu

  1. Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
  2. Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
  3. Fork repository và làm thay đổi trên một nhánh.
  4. Mở pull request có tham chiếu số hiệu của issue.

Issue khác của PRQL/prql

Tất cả issue của PRQL/prql

Issue tương tự

Thêm issue về Rust

Nhận issue mới trong hộp thư của bạn

Bản tóm tắt ngắn những issue GitHub phù hợp với người mới.