Skip to content
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

Parameterized Query. #117

Open
LibertyBeta opened this issue Mar 2, 2020 · 6 comments
Open

Parameterized Query. #117

LibertyBeta opened this issue Mar 2, 2020 · 6 comments

Comments

@LibertyBeta
Copy link

So, I might be a little thick, but it seems like this package doesn't use a real parameterized query. For example a query written as: Select * from people where id = $1 where the parameter values are sent separately from the query. Instead we are relying on the escaping of the data in the library. And while this look nice, it still makes me wary.

Will this be supported in the future?

@isoos
Copy link
Collaborator

isoos commented Mar 2, 2020

@LibertyBeta: I think it would be nice to have that, but I'm not aware of anybody wanting to implement it. Do you have any data what it would mean in the query execution performance, or would it provide other features that would be a strong incentive to implement it? Would you be interested in implementing it?

@LibertyBeta
Copy link
Author

LibertyBeta commented Mar 2, 2020

Primary feature I can think of is a more standardized way of handling inject and typing. It's not perfect, but very nice.

As to requirements/cost to implement I would have to do some research, consult with people who know more.

Edit: I would require wrapping some work with prepare statements.

@joeconwaystk
Copy link
Contributor

I'm not sure what this issue is in reference to. Prepared statements and parameterized queries are already implemented; this occurs in the backend/frontend protocol communication. I'm not sure if this issue is referring to what is happening, what should be happening?

@isoos
Copy link
Collaborator

isoos commented Mar 2, 2020

@joeconwaystk: some queries still use PostgresTextEncoder (e.g. execute calls), which is probably not the most efficient.

@joeconwaystk
Copy link
Contributor

Sure, but that is intentional. This issue sounds more a documentation issue?

@LibertyBeta
Copy link
Author

I think it might be an issue with the documentation then, as the syntax is different from the use of the PREPARE statement, so typechecking/escaping appears to happen only client side. Maybe something like the docs in node-postgres?

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

No branches or pull requests

3 participants