Dimitri Fontaine wrote: > 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?
Please give my DDL deparsing patch a look. There is a portion there about deparsing ALTER TABLE specifically; what it does is save a list of subcommands, and for each of them we either report the OID of the object affected (for example in ADD CONSTRAINT), or a column number (for ALTER COLUMN RENAME, say). It sounds like you would like to have some extra details returned: for instance the "does the whole of it require a table rewrite" bit. It sounds like it can be trivially returned in the JSON object as a boolean (not sure if it would be attached to each individual subcommand, or at the global level), even if it doesn't play a role in the "fmt" string --- similar to how we're labelling different kinds of constraints in an ADD CONSTRAINT subcommand with the type of constraint being added. Not real sure if the functionality you propose would be just returned in the JSON object (so the user would be in charge of extracting it, or perhaps we provide additional auxiliary functions that examine the JSON), or separately. Elsewhere Pavel was complaining that JSON is not plpgsql-friendly; something to consider here too. Anyway if you're able to help the DDL deparse patch by implementing some of the missing commands (which could help you with your proposal here), that would be much welcome. -- Álvaro Herrera http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers