prepare statement w/o values #24
Comments
|
dang! I'll take a look at this after work today. |
|
I cannot reproduce. Can I get a code sample, version of pg you're using, version of node you're using, and operating system? |
|
Sure. Please, take a look at https://gist.github.com/929626 |
|
Okey dokey...thanks for the awesome gist. I see the issue. With node-postgres the first time you issue a named query it is parsed, bound, and executed all at once. Every subsequent query issued on the same connection with the same name will automatically skip the "parse" step and only rebind and execute the already planned query. Currently node-postgres does not support a way to create a named, prepared query and not execute the query. This feature is supported within libpq and the client/server protocol (used by the pure javascript bindings), but I've not directly exposed it in the API. I thought it would add complexity to the API without any real benefit. Since named statements are bound to the client in which they are created, if the client is disconnected and reconnected or a different client is returned from the client pool, the named statement will no longer work (it requires a re-parsing). Here's an example of how it works currently: |
|
In fact, I've found the current behavior quite well-suited. I can perfectly live with this "lazy-preparation" way. Thanks. Closing |
* Revert "When connection fail, emit the error. (#28)" This reverts commit 6a7edab. The callback passed to `Pool.prototype.connect` should be responsible for handling connection errors. The `error` event is documented to be: > Emitted whenever an idle client in the pool encounters an error. This isn’t the case of an idle client in the pool; it never makes it into the pool. It also breaks tests on pg’s master because of nonspecific dependencies. * Don’t create promises when callbacks are provided It’s incorrect to do so. One consequence is that a rejected promise will be unhandled, which is currently annoying, but also dangerous in the future: > DeprecationWarning: Unhandled promise rejections are deprecated. In the future, promise rejections that are not handled will terminate the Node.js process with a non-zero exit code. The way callbacks are used currently also causes #24 (hiding of errors thrown synchronously from the callback). One fix for that would be to call them asynchronously from inside the `new Promise()` executor: process.nextTick(cb, error); I don’t think it’s worth implementing, though, since it would still be backwards-incompatible – just less obvious about it. Also fixes a bug where the `Pool.prototype.connect` callback would be called twice if there was an error. * Use Node-0.10-compatible `process.nextTick`
Hi!
How do I prepare a statement w/o binding values and executing it, just for future use as named query? The absense of
valueskey in configuration parameters causes unhandlederrorevent so farTIA,
--Vladimir
The text was updated successfully, but these errors were encountered: