Andres Freund <and...@2ndquadrant.com> wrote: >> We most particularly *don't* want DDL to replicate automatically, >> because the schema changes are deployed along with related >> software changes, and we like to pilot any changes for at least a >> few days. Depending on the release, the rollout may take a >> couple months, or we may slam in out everywhere a few days after >> the first pilot deployment. > Thats a sensible for your use-case - but I do not think its thats > the appropriate behaviour for anything which is somewhat > out-of-the box... Right. We currently consider the issues involved in a change and script it by hand. I think we want to continue to do that. The point was that, given the variety of timings and techniques for distributing schema changes, maybe is was only worth doing that automatically for the most constrained and controlled cases. >> So you could certainly punt all of this for any release as far as >> Wisconsin Courts are concerned. We need to know table and column >> names, before and after images, and some application-supplied >> metadata. > I am not sure were going to get all that into 9.3. Sure, that was more related to why I was questioning how much these use cases even *could* integrate -- whether it even paid to *consider* these use cases at this point. Responses from Robert and you have pretty much convinced me that I was being overly pessimistic on that. One fine point regarding before and after images -- if a value doesn't change in an UPDATE, there's no reason to include it in both the BEFORE and AFTER tuple images, as long as we have the null column bitmaps -- or some other way of distinguishing unchanged from NULL. (This could be especially important when the unchanged column was a 50 MB bytea.) It doesn't matter to me which way this is optimized -- in our trigger-based system we chose to keep the full BEFORE tuple and just show AFTER values which were distinct from the corresponding BEFORE values, but it would be trivial to adapt the code to the other way. Sorry for that bout of pessimism. -Kevin
-- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
