Previously we selected * from pg_authid, which had a few negative effects.
First, this is vague and sloppy: we should select what we want,
especially as the fields in pg_authid differ across Postgres versions.
Second, because the fields in pg_authid differ across Postgres versions,
this introduces a variety of opaque bugs for users trying to get
pgbedrock working with Postgres versions that aren't explicitly
supported. If a field is missing from that version of pg_authid then a
KeyError or something similar will come up further in the innards of
pgbedrock, but the issue was much earlier in the results from the
SELECT. If an extra (unexpected) field is in pg_authid then pgbedrock
may fail as well. In both situations, the solution is to be explicit
about what we request from the database and to fail on that query.
Previously we selected * from pg_authid, which had a few negative effects.
First, this is vague and sloppy: we should select what we want, especially as the fields in pg_authid differ across Postgres versions.
Second, because the fields in pg_authid differ across Postgres versions, this introduces a variety of opaque bugs for users trying to get pgbedrock working with Postgres versions that aren't explicitly supported. If a field is missing from that version of pg_authid then a KeyError or something similar will come up further in the innards of pgbedrock, but the issue was much earlier in the results from the SELECT. If an extra (unexpected) field is in pg_authid then pgbedrock may fail as well. In both situations, the solution is to be explicit about what we request from the database and to fail on that query.