> If we push the responsibility back to dblink, we might as well export
> conninfo_parse() or some wrapper thereof and let dblink simply check for
> a non-null password from the very beginning.
That's not totally unreasonable, since we already export the
PQconninfoOption struct ...
> Or perhaps we should modify conninfo_parse() to throw an error if it
> sees the same option more than once. Then dblink could prepend
> pgpassfile (or ignore_pgpass) to the beginning of the connstr and not
> have to worry about being overridden. Not sure if the backward
> compatibility hit is worth it though.
... but I think I like the second one better; multiple specifications of
an option seem like probably a programming error anyway. It's a close
call though. Exporting the parse code might enable other uses besides
this one.
In either case we'd still need a check after connection to verify that
the password actually got *used*, so I guess that
PQconnectionUsedPassword isn't dead, just incomplete.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
No comments:
Post a Comment