Movatterモバイル変換


[0]ホーム

URL:


Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

Sign up
Appearance settings

Support for templated parameters#396

reteps started this conversation inIdeas
May 9, 2025· 1 comments· 11 replies
Discussion options

It would be excellent to have support for templated parameters:

SELECT*WHEREaq.id= $assessment_question_idFROM  assessment_questionsAS aq;

Where$assessment_question_id is replaced either with:

  • a appropriate value for the column type
  • the name of the parameter in quotes

Currently, I get an error:

Error message on `0.6.1`
yarn postgrestools check apps/prairielearn/src/models/dummy.sqlapps/prairielearn/src/models/dummy.sql:1:1 syntax ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━  ✖ Invalid statement: syntax error at or near "$"  > 1 │ SELECT      │ ^^^^^^  > 2 │   *  > 3 │ WHERE  > 4 │   aq.id = $assessment_question_id  > 5 │ FROM  > 6 │   assessment_questions AS aq;      │   ^^^^^^^^^^^^^^^^^^^^^^^^^^^    7 │Checked 1 file in 12ms. No fixes applied.Found 1 error.check ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━  ✖ Some errors were emitted while running checks

SQLFluff takes the second approach (replace the templated parameter with the name in quotes), andallows you to configure templating, as well as overriding the replacement behavior.

[sqlfluff:templater:placeholder]param_style = dollarassessment_question_id = 0

Default:

SELECT  *WHERE  aq.id = 'assessment_question_id'FROM  assessment_questions AS aq;

With customization:

SELECT  *WHERE  aq.id = 0FROM  assessment_questions AS aq;

Related:

You must be logged in to vote

Replies: 1 comment 11 replies

Comment options

A simple transformation to a quoted version of the variable name allows for type diagnostics:
CleanShot 2025-05-21 at 21 44 43@2x

Perhaps an approach like:

  1. transform to quoted version, and mark transformation from templated variable (to allow for parsing)
  2. upon typechecking, transform into the appropriate null type to avoid any diagnostic errors, or simply ignore the diagnostics if it came from a transformed variable.

If this seems like a reasonable approach, I would be happy to try and get a PR up.

You must be logged in to vote
11 replies
@psteinroe
Comment options

It would replace libpg_query entirely.

I am currently contributing a bit tohttps://squawkhq.com because the parser there is quite advanced compared to any other attempt I have seen so far.

@reteps
Comment options

I am also aware of thesqruff parser (https://github.com/quarylabs/sqruff/blob/main/crates/lib-dialects/src/postgres.rs), but I don't know how it compares to squawk.

@reteps
Comment options

The configuration could take inspiration fromhttps://github.com/UniqueVision/plpgsql-lsp?tab=readme-ov-file#query-parameters

{  "plpgsqlLanguageServer.queryParameterPattern": ":[A-Za-z_][A-Za-z0-9_]*"}
@psteinroe
Comment options

hey! i think we can now start to work in this. our approach now is to

  • use a custom lexer to not already break there (done),
  • bring a custom binding for libpg_query in (use the custom libpg_query binding #453),
  • build a preprocessor for libpg_query that replaces the parameters based on a config.

I think this is the easiest and most robust approach. the important part was the custom lexer that supports all kind of parameters.

@reteps
Comment options

Awesome!

Sign up for freeto join this conversation on GitHub. Already have an account?Sign in to comment
Category
Ideas
Labels
None yet
2 participants
@reteps@psteinroe

[8]ページ先頭

©2009-2025 Movatter.jp