Fix alias_dsn detection for --list-dsn and -D

[ChrisJr404]

Description

--list-dsn and -D/--dsn read the config with a bare load_config(pgclirc, config_full_path) that skips the packaged default pgclirc, unlike everything else in pgcli which goes through get_config. That's the root cause of #1489.

Two ways it bites:

• --list-dsn runs before PGCli() is constructed, so on a fresh install the config file hasn't been written yet. load_config then reads a non-existent file, cfg["alias_dsn"] raises KeyError, and the broad except Exception swallows it and prints Invalid DSNs found in the config file with exit 1. No template gets written either, so there's nothing for the user to edit. To someone who did add an alias it just looks like the section is being ignored.
• -D <alias> has the same bare read plus a cfg["main"] access further down (timezone handling). If the user's config only contains an [alias_dsn] block, [main] isn't there and it blows up after resolving the alias.

Switching both call sites to get_config(pgclirc) fixes it: get_config writes the default template when the file is missing and merges the packaged default, so the expected sections ([main], [alias_dsn]) are always present and aliases resolve the same way they do everywhere else.

I couldn't reproduce the original report on a config that already has a populated [alias_dsn] (that path works), but the fresh/minimal-config cases above are reproducible and match the reported symptoms.

Tests in tests/test_alias_dsn.py: fresh config now lists nothing and exits 0 instead of erroring; populated [alias_dsn] is listed; -D <alias> resolves to the right connection; -D <unknown> still errors. The fresh-config and -D-resolve tests fail on main and pass with this change.

Checklist

• I've added this contribution to the changelog.rst.
• I've added my name to the AUTHORS file (or it's already there).
• I installed pre-commit hooks (pip install pre-commit && pre-commit install).
• I verified that my changes work as expected (this may include manually testing them in your local environment, or in other available environments). Cross this out if not relevant (for example, if you're making a documentation change).
• Please squash merge this pull request (uncheck if you'd like us to merge as multiple commits)

[j-bennet]

Nice!

[j-bennet]

@ChrisJr404 Nice work! The fix looks beautifully minimal. But I would suggest a different approach.

When the user wants to --list-dsn, it's supposed to be a lightweight command that only reads the config. If we encounter no config file, why do the extra work to write one? It's already clear that there's nothing to list. I'd add special handling for KeyError (or whatever the error raised) instead.

With the -D <alias>, the case is not as clear cut. But if the file exists, we shouldn't need to write it. The user might prefer a minimal file with just an [alias_dsn] section, and I think we should tolerate having no [main] section.

What do you think?

[ChrisJr404]

That makes sense, and I agree the current approach does more work than it should. I'll rework it so:

• --list-dsn treats a missing config as simply "nothing to list" (handling the KeyError/missing-section case) instead of writing a fresh config just to read it back.
• -D <alias> reads from the existing file when present and does not rewrite it; it only needs to resolve the one [alias_dsn] entry.

That keeps both paths read-only in the common case. I'll push an update along those lines.