Robert Haas <robertmh...@gmail.com> writes: > But the immediate problem is that pg_dump.c is heavily reliant on > global variables, which isn't going to fly if we want this code to use > threads on Windows (or anywhere else). It's also bad style. So I > suggest that we refactor pg_dump.c to get rid of g_conn and g_fout.
I've looked at that a bit in the past and decided that the notational overhead would be too much. OTOH, if we're going to be forced into it in order to support parallel pg_dump, we might as well do it first in a separate patch. > ... But it > seems possible that we might someday want to dump from one database > and restore into another database at the same time, so maybe we ought > to play it safe and use different variables for those things. So I'm > inclined to think we could just add a "PGconn *remote_connection" > argument to the Archive structure (to go with all of the similarly > named "remote" fields, all of which describe the DB to be dumped) and > then that would be available everywhere that the Archive itself is. I always thought that the "remote" terminology was singularly unhelpful. It implies there's a "local" connection floating around somewhere, which of course there is not, and it does nothing to remind you of whether the connection leads to a database being dumped or a database being restored into. If we are going to have two fields, could we name them something less opaque, perhaps "src_connection" and "dest_connection"? 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