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