4 ms·
> It's remarkably mature and ergonomical. The aspect of that that's hit me a few times recently is how unusual (but great) it is that it and all other (that I
by OJFord 4y ago
> It's remarkably mature and ergonomical.
The aspect of that that's hit me a few times recently is how unusual (but great) it is that it and all other (that I've needed, anyway) pg tools use the same args for connecting to a database in the same way.
Once I realised, I renamed the `psql` wrapper script I'd written (takes an arg for the namespace name, looks up correct RDS host etc. for it) to `pgenv`, adding another argument for the real executable to run (i.e. `psql` is now `pgenv real_psql "$@"`) so it can also be used with dump, upgrade, vacuum...
- gen220 4y agoYou might be interested in the existence of `.pgpass` [1] and `.pg_service.conf` [2] I learned about them recently, it's been a massive quality of life improvement. [1]: https://www.postgresql.org/docs/current/libpq-pgpass.html https://www.postgresql.org/docs/current/libpq-pgpass.html [2]: https://www.postgresql.org/docs/current/libpq-pgservice.html https://www.postgresql.org/docs/current/libpq-pgservice.html
- OJFord 4y agoWith an AWS config style 'credential_process' option that'd be ideal. My script pulls the value from Terraform, which of course I could just dumo into one of those files, but it does occasionally change; it's very convenient that it just keeps on working (especially as it's also used in CI, so nothing to change and commit for it to work with new values). Thanks though, I didn't know about the latter, and I think I've only heard of pgpass from error messages and such, not actually looked into it before.