Use PGPASSWORD env var for postgres test credentials

[mcraveiro]

Summary

• Add test_helpers.hpp with make_credentials() utility function
• Function checks PGPASSWORD env var, falls back to "password" if not set
• Update all 69 postgres test files to use the new helper

This allows running tests against an existing postgres instance without requiring password to be "password".

Test plan

• Build succeeds
• test_aggregations passes
• test_listen_notify tests pass (file with 5 credential usages)

🤖 Generated with Claude Code

[mcraveiro]

Note: I've added this PR because I already have a Postgres instance running on my machine and I rather run the tests against it.

[liuzicheng1987]

@mcraveiro , I like the initiative, but I think it should be the same for all relevant databases. In other words, if we're going to do this for the postgres tests, we should also do it the the MySQL tests.

[mcraveiro]

Thanks for the review. I'll have a gander to see if everyone supports a PGPASSWORD equivalent, presumably this must be an established pattern.

[mcraveiro]

OK I did some analysis with Qwen and I think maybe this is not the best approach. Here are the results of the analysis in full, I'll then add my thoughts

Analysis by Qwen

Authentication Environment Variables Comparison

Database	PGPASSWORD Equivalent	Status & Security Notes	Recommended Alternative
PostgreSQL	PGPASSWORD	✅ Exists but discouraged – password visible in process list/environment to other users on the system [[40]]	Use .pgpass file with strict permissions (0600)
MySQL	MYSQL_PWD	⚠️ Deprecated since MySQL 8.0 – explicitly marked insecure because passwords are exposed to any user who runs ps [[52]]	Use .my.cnf option file with [client] section or encrypted .mylogin.cnf created via mysql_config_editor [[67]]
SQLite	None	✅ No authentication mechanism – SQLite is a file-based database with no native username/password concept [[24]]	Rely on OS filesystem permissions; optional encryption via SQLCipher or SEE extension (not standard) [[83]]
DuckDB (local)	None	✅ No authentication for local/in-memory databases – security relies on filesystem permissions [[77]]	Filesystem permissions; no password-based auth in standard distribution
DuckDB (MotherDuck/cloud)	None	⚠️ Uses tokens, not password environment variables – e.g., motherduck_token in connection string [[89]]	Browser-based auth or access tokens stored securely (not in env vars) [[88]]
DuckDB (external services)	Service-specific vars	Uses standard cloud provider vars (e.g., AWS_ACCESS_KEY_ID) for S3/Azure access, not database passwords [[73]]	CREATE SECRET statements preferred over environment variables to avoid leakage [[73]]

Key Differences Highlighted

1. Fundamental Architecture Difference:
   SQLite and standard DuckDB are embedded/file-based databases without client-server architecture, so they lack PostgreSQL/MySQL-style authentication entirely. Security is enforced at the OS/filesystem level rather than within the database engine.

2. MySQL's Deprecation:
   While MySQL technically has MYSQL_PWD, Oracle explicitly deprecated it due to security risks – it's functionally equivalent to PostgreSQL's discouraged PGPASSWORD, but with stronger official warnings against its use [[52]].

3. Cloud vs. Local DuckDB:
   Only DuckDB's cloud offerings (MotherDuck) require authentication, and even then they use token-based auth rather than password environment variables. Local DuckDB instances have no authentication layer.

4. Secure Alternatives:
   All systems that support password-based auth recommend file-based credential storage with strict permissions over environment variables:

   • PostgreSQL: .pgpass (0600 permissions)
   • MySQL: .mylogin.cnf (encrypted via mysql_config_editor) or .my.cnf (0600 permissions)
   • DuckDB (cloud): Tokens stored in application config/secrets manager, not env vars

💡 Security Best Practice: Environment variables like PGPASSWORD/MYSQL_PWD should be avoided in production. They're visible to other processes on the same system and appear in process listings (ps, /proc). Always prefer protected credential files or secrets managers for automated workflows.

My thoughts

Since this is not supported universally, maybe it's best to define a variable for sqlgen? something like:

• SQLGEN_TEST_PASSWORD

We could then use this in a uniform manner across databases.