Toward pg_upgrade
От | David Fetter |
---|---|
Тема | Toward pg_upgrade |
Дата | |
Msg-id | 20050714013550.GB11663@fetter.org обсуждение исходный текст |
Ответы |
Re: Toward pg_upgrade
Re: Toward pg_upgrade |
Список | pgsql-hackers |
Folks, I'm sure I'm not the first to bring up this way of doing pg_upgrade, but perhaps I can help seed a fruitful discussion on the matter. As background, I'd like to go over our policy of, "The code patch must be accompanied by any doc patches that it implies." I believe that this policy is good and wise, as it has helped produce both extremely high code quality and product usability over the years, and that it will continue to do the same as time goes on. So here's my Modest Proposalâ¢. Where the rule now reads, The code patch must be accompanied by any doc patches that it implies. It should read, The code patch must be accompanied by any doc patches *and any needed upgrade transformations* that it implies. By "upgrade transformations," I mean: * Things that change the storage format from the pre-patched version to what the post-patched version, and * Things that transform configuration files from the pre-patched version to the post-patched version. * The ever-popular Stuff Dave Hasn't Thought Of That People Bark Their Shins On. Ideally, these transformations would be both idempotent and reversible, although I understand that they may, by their nature, be neither. Advantages of making this policy change: * Pg_upgrade actually happens as a matter of routine * It's testable one changeat a time Disadvantages: * Increased work on the front-end for new changes * Higher barriers to entry Cheers, D -- David Fetter david@fetter.org http://fetter.org/ phone: +1 510 893 6100 mobile: +1 415 235 3778 Remember to vote!
В списке pgsql-hackers по дате отправления: