On 21 December 2012 14:48, Robert Haas <robertmh...@gmail.com> wrote:
> I predict that if we commit this, it will > becomes a never-ending and irrecoverable font of trouble. Event triggers are a new feature with many powerful uses: replication, online upgrade, data transport. New features require extra code. To decide how big a maintenance burden, we need to look at whether we want the feature, and if we have it, how much code it would be to maintain it. pg_dump needs to dump what is there, so dumping "current state" information is required. That can be accessed from catalog, but requires significant extra code to bring that all back together into DDL text. pg_dump is useful for schema backups and pg_upgrade. This code already exists in core. Replication needs to see "delta" information, so we can track changes as they happen. Trying to deduce exact deltas by diffing two "current state" dumps is close to impossible. The only way is a "delta" stream. This would be used by replication and on-line upgrade. This code can be added to core by the patches under discussion. The code is broadly comparable between "current state" and "delta". It's basically just assembling the text of DDL statements from available information. In one case from the catalog, in the other case from the command parse/execution trees. It's not especially hard to code, nor will it be fiddly or difficult to understand - just developing normalised text versions of the change in progress. Normalisation is important and useful; we spent time in 9.2 doing things the right way for pg_stat_statements. In both cases, the code really should live in core. So we can tie the code directly to each release. Realistically, doing things outside core means there are often holes or problems that cannot be easily solved. That seems almost certain to be the case here. pg_dump maintenance is required but its not a huge burden. pg_dump hasn't slowed down the addition of new DDL features. It just requires a little extra code, mostly very simple. The PostgreSQL project needs rewrite support for DDL, so it will come to exist inside, or outside core. Knowing it is there, being able to rely on that, means we'll make faster progress towards the new features we are building. The approach proposed here has been discussed over many years, minuted in detail at cluster hackers meetings: "DDL Triggers". My thoughts are that the approach here has been well thought through and is exactly what we need. It *is* extra code, but not complex code, and it is code designed to bring us closer to our goals, not to hamper the development of new DDL statements. With the right tests, the changes required would be easy to spot and add code for them. It looks to me that we already have a good suggestion on exactly how to do that (from Robert). So overall, it certainly is worth thinking hard about whether we should include the rewrite code. Balancing the costs and the benefits, I think we should include. -- Simon Riggs 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
