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