brianc / node-postgres

PostgreSQL client for node.js.
https://node-postgres.com
MIT License
12.19k stars 1.21k forks source link

service= connection parameter #416

Open hacker opened 11 years ago

hacker commented 11 years ago

The native libpq provides a nice way of central maintenance of connections across applications for example in ~/.pg_service.conf file by using service= connection parameter. Naturally when I tried to use postgresql://?service=something connection url it didn't work. As I believe (after looking into connection-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;)).

brianc commented 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.

brianc commented 11 years ago

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:

hacker commented 11 years ago

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.

hacker commented 11 years ago

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 ;)

behrang commented 7 years ago

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).

charmander commented 7 years ago

Related: https://github.com/brianc/node-postgres/issues/1393#issuecomment-319308021

jgrocha commented 4 years ago

+1 to have libpq service connection parameter supported.

lechner commented 3 years ago

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".

charmander commented 3 years ago

especially if the patch above is all it takes

The referenced patch only works for pg-native, not the primary pure-JS driver.

tragiclifestories commented 3 years ago

This would be helpful at my place too, where we use the service file interface to make mTLS easier.