Skip to content

render_literal_bindparam() naively calls cached_bind_processor #2838

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
sqlalchemy-bot opened this issue Oct 14, 2013 · 3 comments
Closed

render_literal_bindparam() naively calls cached_bind_processor #2838

sqlalchemy-bot opened this issue Oct 14, 2013 · 3 comments
Labels
bug Something isn't working high priority sql
Milestone

Comments

@sqlalchemy-bot
Copy link
Collaborator

Migrated issue, originally created by Michael Bayer (@zzzeek)

I think we need a new method on type that's specific to rendering a type for literal SQL. At the moment, a string type on an encoding backend can pass in a bytes into render_literal_value (see test.sql.test_types:EnumTest.test_mock_engine_no_prob using Oracle backend on python3). We're working around this by re-decoding the bytes in the method, but more elaborate bind processor schemes will need to be aware of literal SQL and naturally this should be type-based in any case.

@sqlalchemy-bot
Copy link
Collaborator Author

Michael Bayer (@zzzeek) wrote:

initial idea is in the ticket_2838 branch at bc5834d6431663ad2a03677af87dd96a8de923e1. we'll move the whole concept of literal bind rendering into the type system.

the String type will also need to determine if encoding is needed here.

@sqlalchemy-bot
Copy link
Collaborator Author

Michael Bayer (@zzzeek) wrote:

4663ec9

@sqlalchemy-bot
Copy link
Collaborator Author

Changes by Michael Bayer (@zzzeek):

  • changed status to closed

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working high priority sql
Projects
None yet
Development

No branches or pull requests

1 participant