Bruce Momjian escribió: > Magnus Hagander wrote: > > For the case of upgrading, it wouldn't work. But there are certainly > > other cases where it would help. Say from your central pgadmin console > > administering 10 servers from 3 different major release trees :-(
What's wrong with providing statically-linked pg_dump-8.2, pg_dump-8.3 and so on, and asking the user which one to use (depending on the target server version)? > Using the new pg_dump for dumping older versions during an ugprade is > just inconvenient and something we should not need to do. At the worst > we should have a way for us to upgrade the older version of pg_dump with > whatever functionality we need and just tell people to be running the > most recent minor release before upgrading. > > What cases on the past have needed the new pg_dump? Dependency handling IIRC in 7.3 (or was it 7.2?) was a big change for pg_dump, and I don't think we would have liked to backpatch the pg_dump changes. Also, AFAIK the sequences stuff with OWNED BY also needed the newer pg_dump, which is more recent (8.2?). I don't think it's as rare as you suggest. -- Alvaro Herrera http://www.CommandPrompt.com/ PostgreSQL Replication, Consulting, Custom Development, 24x7 support ---------------------------(end of broadcast)--------------------------- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
