Peter Eisentraut <peter_e@gmx.net> writes:
> The argument elsewhere in this thread was that the reason for putting
> this in the connection options was so that you do *not* have to patch up
> every client to be able to use this functionality. If you have to add
> separate options everywhere, then you might as well just have a separate
> libpq function to initiate the session.
Right, Andres was saying that we had to do both (special switches that
lead to calling a special connection function). I'm not terribly happy
about that, because it will greatly constrain the set of programs that are
able to connect to standalone backends --- but I think that there are some
in this discussion who want that, anyway. In practice, as long as psql
and pg_dump and pg_upgrade can do it, I think we've covered most of the
interesting bases.
To my mind, the "create a socket and hope nobody else can get to it"
approach is exactly one of the main things we're trying to avoid here.
If you'll recall, awhile back we had a big discussion about how pg_upgrade
could positively guarantee that nobody messed with the source database
while it was working, and we still don't have a bulletproof guarantee
there. I would like to fix that by making pg_upgrade use only standalone
backends to talk to the source database, never starting a real postmaster
at all. But if the standalone-pg_dump mode goes through a socket, we're
back to square one on that concern.
regards, tom lane