It struck me while looking at the regression test arrangements for
postgres_fdw that as things are set up, the default username for
outgoing connections is going to be that of the operating system
user running the postmaster. dblink is the same way.
Now, this might not be the world's worst default, but it's got to be a
pretty bad one. The OS username of the server isn't really supposed to
be exposed at all on the SQL level. And to the extent that it matches
the bootstrap superuser's SQL name, it's still a non-POLA-satisfying
default for any user other than the bootstrap superuser.
IMO it would make a lot more sense for the default to be the name of the
current database user. Either that, or insist that the outgoing
username not be defaultable at all; though I'm not sure we can do the
latter without breaking the regression tests, since those are supposed
to be agnostic as to the name of the superuser running them.
A related issue is that libpq will happily acquire defaults from the
server's environment, such as PGPORT. This seems like it's also
exposing things that shouldn't be exposed. Unfortunately, I think we're
depending on that for the dblink and postgres_fdw regression tests to
work at all when the postmaster is listening to a nondefault port (ie,
"make check").
Is there a better way to handle all this? It may be too late to rethink
dblink's behavior anyhow, but perhaps it's not too late to change
postgres_fdw. I think though that once we let 9.3 out the door, it
*will* be too late to make any major changes, because postgres_fdw's
usage is going to go through the roof now that it can do remote updates.
regards, tom lane
