Support RDS connection json in pg-connection-string `parse`

Per @hjr3 moving this over from pg-connection-string’s repo.

This is perhaps a little “too cute”, but for applications/libraries that use Amazon’s RDS for their postgres db, RDS/CloudFormation can auto-manage the database user/password as secrets in the AWS Secrets Manager.

See here, which is not terribly succinct, but basically CloudFormation auto-secrets a secret, and “attaches” it to the PG instance, so that applications can (assuming they’re granted access) look up the secret to get the connection info.

Helpfully, the secret has both user/pass as well as connection information, i.e. it’s basically all the connection info an application needs, encoded in JSON that looks like:

{
  "host":"whateverrds.amazon.com",
  "port":5432,
  "username":"...",
  "password":"...",
  "dbname":"..."
}

(Without newlines, just formatted for the issue.)

This value is typically passed to the application as an environment (i.e. read securely by the instance/container when it boots up), similar to how PG connection info is normally passed, but now as this JSON key/value pairs instead of the OG postgres:// connection string.

For my library, I’d like to easily support “runs with existing postgres://... connections” as well as “just pass the RDS connection JSON thingy”, and have both just work.

Which I can handle manually, but it seems neat if parse(...) itself would recognize the ^ format (i.e. if the first char of the string is a { then assume “this is RDS-style JSON”) and return the appropriate ConnectionInfo.

Granted, this adds some RDS-specific behavior to node-postgres/pg-connection-string, and fwiw I don’t know why they didn’t just use a postgres://... connection string instead of this JSON value 🤷, but given how widespread RDS is, it seems potentially worth the ROI to implement this “pretend/great JSON is a connection string” once here, and have all node-postgres / RDS / RDS-managed-secret users be able to use it.

I can work on a PR if this sounds okay.

[brianc]

as an aside just in general I try to limit the amount of new features I add directly to pg, and somewhat even to the other modules in this repo just because it’s quite a bit to maintain. I want to be diligent and always driving pg forward, so in order to do that I have to limit what stuff I take on, otherwise (as has happened to me in the past) I get overwhelmed and I go into a hidey hole for a while and burn out and things languish. So…it’s a confluence of reasons, but the idea itself of making connecting to rds easier is definitely good & worth pursuing if you’re interested in it!

[sehrope]

+1 to keeping something like this separate from the core pg module. It’s not specific to pg and it’s not even standardized by RDS for the specific fields included in the JSON (e.g. you can “username” to “user”, “password” could be “auth”). You’d also be making other assumptions about the PGSSLMODE, CA, and a bunch of other fields as well.

Create a separate module, something like rds-pg-config, that takes a single JSON field and returns a pg compatible config object. That’d be a decent place to document the specific choices of field names for username, password, host, etc, and also the specific defaults that would apply to RDS. Could even pick a specific env var to look at by default.

Then you’d use it via:

const pg = require('pg');
const rdsPgConfig = require('rds-pg-config');

const pool = new pg.Pool({
    ...rdsPgConfig(process.env.SOME_ENV_VAR_GOES_HERE),
    // ...other pg options you want to override
    // ...pool options
});