Skip to content

Ensure param substitution works for c-style formatted queries - #147

Merged
long2ice merged 5 commits into
long2ice:devfrom
baconfield:dev
Jun 15, 2026
Merged

Ensure param substitution works for c-style formatted queries#147
long2ice merged 5 commits into
long2ice:devfrom
baconfield:dev

Conversation

@baconfield

Copy link
Copy Markdown
Contributor

Fixing param substitution for %(name)s formatting, e.g. cases like:

await self.cursor.execute(
    """
    SELECT
        EXISTS(
            SELECT 1
            FROM table_a
            WHERE profile_id = %(profile_id)s
        ) AS has_a,
        EXISTS(
            SELECT 1
            FROM table_b
            WHERE profile_id = %(profile_id)s
        ) AS has_b
    """,
    {"profile_id": profile_id}
)

#141 (comment)

@dmkulazhenko

Copy link
Copy Markdown
Contributor

#141 (comment)

@dmkulazhenko dmkulazhenko left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM!

But Im not sure if in global this approach should be here 🤔

As I said in #141 (comment) approach of supporting both c-style format and modern format looks kinda pointless. Maybe full revert of #141 is enough.

@baconfield @stankudrow @long2ice what do you think?

@stankudrow

Copy link
Copy Markdown
Contributor

LGTM!

But Im not sure if in global this approach should be here 🤔

As I said in #141 (comment) approach of supporting both c-style format and modern format looks kinda pointless. Maybe full revert of #141 is enough.

@baconfield @stankudrow @long2ice what do you think?

Hello,

Could you provide the rationale for the #141 ? What were reasons why formatting via the .format() method is viable? I meam, if not only C-style is enough, then this approach may work, otherwise, this PR should revert the previous.

@dmkulazhenko

Copy link
Copy Markdown
Contributor

LGTM!
But Im not sure if in global this approach should be here 🤔
As I said in #141 (comment) approach of supporting both c-style format and modern format looks kinda pointless. Maybe full revert of #141 is enough.
@baconfield @stankudrow @long2ice what do you think?

Hello,

Could you provide the rationale for the #141 ? What were reasons why formatting via the .format() method is viable? I meam, if not only C-style is enough, then this approach may work, otherwise, this PR should revert the previous.

I described situation in linked comment #141 (comment)

@baconfield

Copy link
Copy Markdown
Contributor Author

To double check before I add any commits, is the project wanting to support just %(name)s (pyformat/extended c-style) style param substitution, or both {name} and %(name)s styles?

@nils-borrmann-tacto

Copy link
Copy Markdown
Contributor

I agree with rolling back that change. format-style substitution also clashes with clickhouses native server-side parameters (which I'm working on supporting).

@stankudrow

stankudrow commented Mar 12, 2026

Copy link
Copy Markdown
Contributor

@baconfield , @dmkulazhenko , hello.

LGTM, so can be merged IMHO (I am not a maintainer)

@stankudrow

Copy link
Copy Markdown
Contributor

@long2ice , hello. I guess it can be merged if you are happy with the changes.

@long2ice
long2ice merged commit 1af73b3 into long2ice:dev Jun 15, 2026
@stankudrow

Copy link
Copy Markdown
Contributor

@nils-borrmann-tacto , hello, you can rebase your PRs, what is the "most wanted" in your opinion to be pushed forward?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

5 participants