On Fri, 2008-07-25 at 20:26 +0100, Simon Riggs wrote: > On Fri, 2008-07-25 at 11:46 -0700, Joshua D. Drake wrote: > > On Fri, 2008-07-25 at 19:33 +0100, Simon Riggs wrote:
> > > Adding this feature gives a very fast capability to create sample > > > databases, or incremental backups for many cases. > > > > Not sure I buy this argument. I am all for usability and I would be the > > first to shout about the general ridiculousness of pg_dump/all/restore > > but in this case I think Tom is right. This feature could easily be done > > in a script without harassing pg_dump. > > You can do it, yes. But it takes a lot longer. If the time to implement > was similar, then I would immediately agree "feature available already". > > pg_dump is not "harassed" by this. What is lost by adding this feature? Gained. Code complexity. Right now pg_dump does, copy. You are introducing a whole other level of complexity by adding WHERE clause capability. Secondly I don't think it would actually add anything but complexity to the user. How do we deal with this? pg_dump -w "last_update_timestamp < ..." -t 'table*' What I see is a recipe for inconsistent, un-restorable backups without a user realizing what they have done. The only way to deal with the above is: 1. Wildcards aren't allowed if you have -w 2. You dump everything, if the WHERE clause isn't relevant you just dump the whole table I don't like either. I do see utility if you know what you are doing but I think it makes more sense to have it outside of pg_dump. Sincerely, Joshua D. Drake -- The PostgreSQL Company since 1997: http://www.commandprompt.com/ PostgreSQL Community Conference: http://www.postgresqlconference.org/ United States PostgreSQL Association: http://www.postgresql.us/ Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
