Parameterized Query.

[LibertyBeta]

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]

@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]

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.

[itsjoeconway]

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]

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

[itsjoeconway]

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

[LibertyBeta]

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?