On Thu, Oct 2, 2014 at 1:46 PM, Fabrízio de Royes Mello <fabriziome...@gmail.com> wrote: > On Thu, Oct 2, 2014 at 1:30 PM, Dimitri Fontaine <dimi...@2ndquadrant.fr> > wrote: >> >> Hi fellow hackers, >> >> I would like to work on a new feature allowing our users to assess the >> amount of trouble they will run into when running a DDL script on their >> production setups, *before* actually getting their services down. >> >> The main practical example I can offer here is the ALTER TABLE command. >> Recent releases are including very nice optimisations to it, so much so >> that it's becoming increasingly hard to answer some very basic >> questions: >> >> - what kind of locks will be taken? (exclusive, shared) >> - on what objects? (foreign keys, indexes, sequences, etc) >> - will the table have to be rewritten? the indexes? >> >> Of course the docs are answering parts of those, but in particular the >> table rewriting rules are complex enough that “accidental DBAs” will >> fail to predict if the target data type is binary coercible to the >> current one. >> >> Questions: >> >> 1. Do you agree that a systematic way to report what a DDL command (or >> script, or transaction) is going to do on your production database >> is a feature we should provide to our growing user base? >> >> 2. What do you think such a feature should look like? >> >> 3. Does it make sense to support the whole set of DDL commands from the >> get go (or ever) when most of them are only taking locks in their >> own pg_catalog entry anyway? >> >> Provided that we are able to converge towards a common enough answer to >> those questions, I propose to hack my way around and send patches to >> have it (the common answer) available in the next PostgreSQL release. >> > > What you are proposing is some kind of "dry-run" with verbose output?
EXPLAIN ALTER TABLE ? -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers