Suggestion: Add node-postgres-named to easily support named parameters

[n321203]

I would suggest adding support for node-postgres-named
It patches the pg-client to support named parameters (what it does is looking at the named parameters and write a regular array of parameters [$1, $2, $3 etc]...).

That way, we can write more readable queries:

(insertUser.sql):
INSERT INTO users VALUES ($firstname, $lastname)

(now we can write):
db.insertUser( {firstname: 'Peter', lastname: 'Pan'},  fn(...) )

Much more readable than writing queries with $1, $2 etc!

[xivSolutions]

Interesting! Definitely worth looking into...so long as it doesn't mess up any of the internal plumbing in Massive.

On the other hand, taking on another external dependency is something to consider carefully as well.

[n321203]

Yup, I agree. It's actually only ~70 lines of code so another option is to implement something similar directly into massive (and give credit to the author...).

(Update: link is now working)

[xivSolutions]

Ha ha - Yep. Stealing, with some attribution ("code re-use" ;-)), was my thought. That way we can make it available through the API where it makes sense, but retain the indexed params if/where that makes sense.

[dmfay]

This would definitely be cool for scripts & functions (table crud should stick with indexed parameters imo), but it's going to be difficult to implement or integrate there because of how Executable.invoke() sorts out its arguments.

You can pass up to three args: parameters (primitive or array), options (object; currently just used to toggle results streaming), and callback. Since both parameters and options are optional, it checks the types of what you pass it and assumes an object is the options and anything else is the parameters. When using this, the parameters could also be an object, and I don't know if it's possible to resolve that ambiguity while remaining backwards-compatible.

[n321203]

Hmm... sounds like it is impossible without breaking backwards compatibility (if we don't look at the objects and assume the first found object containing the key "stream" is the options object... but that's ugly!)

[n321203]

I would probably change the arguments/signature to:

• If one argument is passed, assume it is the parameters,
• If two arguments is passed, require the first to be the parameters, and the second one to be the options.

That way, the api will change only for people using streams today without any parameters (passing the options object as first argument)

[emfax]

I also think the named parameters thing would be pretty cool. I had a reason to use overloaded SQL functions and named parameters would help that. At the moment, there doesn't seem to be support for overloaded SQL functions.

[dmfay]

It's happening! At least for run and script files!