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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers