Open hacker opened 11 years ago
I'd love to see your patch. I think it would open my eyes a bit more. I'm definitely down for absorbing behavior provided by libpq and adding it into the JavaScript behavior. I do absolutely agree the libpq defaults have more and more drived how I've shaped the JavaScript library.
If it's not too much trouble a pull request is always a great way to discuss, review, and work on code even if its not merged finally. If you're not working on a github fork, any .patch or .diff will be totally fine & I'll see what you've done & come back here to discuss how you think the best implementation should be for node-postgres. At that point I can implement it myself or we can work together on it...whichever you're more comfortable with and have time for. :smile:
I agree, that code speaks better than description, I don't have a fork on github, only a local repo so I'll get back with a diff to you. If my contribution will be more significant than this patch (that I — again — doubt is a final solution) I can of course fork it here as well.
Here is the patch: https://gist.github.com/hacker/4ffb8808a4b4a0947e9d
And I also added this:
['host','user','database','password','port'].forEach(function(p){ delete PG.defaults[p]; });
code to stop it from overriding service settings.
Let me know if you need more comments, suggestions, opinions or a cozy fireside chat ;)
Hi. Is there going to be any support for service
parameter?
Specifying all postgres connection parameters every time is tedious and ~/.pg_service.conf
is more versatile than ~/.pgpass
and allows setting many SSL related parameters.
(PGSERVICE
and PGSERVICEFILE
environment variables are also related).
+1 to have libpq service
connection parameter supported.
Hi, I would also appreciate the service
notation for connection parameters, especially if the patch above is all it takes. PostgreSQL's service files are a great way to manage connection parameters centrally.
@brianc Perhaps this blog post will help "open your eyes".
especially if the patch above is all it takes
The referenced patch only works for pg-native, not the primary pure-JS driver.
This would be helpful at my place too, where we use the service file interface to make mTLS easier.
The native libpq provides a nice way of central maintenance of connections across applications for example in
~/.pg_service.conf
file by usingservice=
connection parameter. Naturally when I tried to usepostgresql://?service=something
connection url it didn't work. As I believe (after looking intoconnection-parameters.js
) many other parameters are also ignored.I am sorry for not providing a patch, but this is because it's a design decision that you need to make, not just changing code. I'd think that the best one can do here is to pass the connection string to the native libpq unchanged somehow, but that may interfere with your idea of making native/js absolutely interchangeable (I think you'll agree though that it should drive the js implementation, not hinder native libpq capabilities).
Meanwhile I have patched my copy to handle service parameter — that also takes ignoring 'host' if it's not set. And deleting stuff from defaults on application startup, because it breaks things. I can, of course, give you my patch, but I do not think it's anywhere near being a good solution, though once you make up your mind about which way to go I'd be glad to help you (especially if I agree with your decision;)).