> BTW, a possible hole in this scheme would be if a user could supply a
> conninfo string that was intentionally malformed in a way that would
> cause a tacked-on pgpassfile option to be ignored by libpq. We might
> need to add some validity checks to dblink, or tighten libpq's own
> checks.
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.
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.
Joe
--
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