Craig Ringer wrote: > Improving this probably needs DDL deparse to be smarter. Rather than just > emitting something that can be reconstructed into the SQL text of the DDL > it needs to emit one or more steps that are semantically the same but allow > us to skip the rewrite. Along the lines of: > > * ALTER TABLE mytable ADD COLUMN somecolumn sometype; > * ALTER TABLE mytable ALTER COLUMN somecolumn DEFAULT some_function(); > * <wait for rewrite data for mytable> > * ALTER TABLE mytable ALTER COLUMN somecolumn NOT NULL;
Compared to the effort involved in getting the current DDL-event capture stuff in event triggers, and writing the extension that creates the JSON representation that expands to SQL commands, this seems easy to do. What currently happens is that we get a list of ALTER TABLE subcommands and then produce a single ALTER TABLE that covers them all. To fix this problem we could mark those ALTER TABLE subcommands that require a table rewrite, and mark them specially; emit a list of the ones before the rewrite as one command, then emit some sort of token that indicates the table rewrite, then emit a list of the ones after the rewrite. The replay code can then "wait" for the rewrite to occur. Since this is all in extension code, it's possible to tailor to the needs you have. (This is the point where I'm extremely happy we ended up creating the hooks and the new pseudo-type separately from the extension containing the JSON-generating bits, instead of having it all be a single piece.) One slight pain point in the above is the handling of ALTER COLUMN / SET NOT NULL. That one currently requires a table scan, which would be nice to avoid, but I don't see any way to do that. -- Álvaro Herrera http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, 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
