On Thu, Dec 6, 2012 at 3:34 PM, Dimitri Fontaine <dimi...@2ndquadrant.fr> wrote: > I think we need to be solving that problem when we implement new firing > points for event trigger. The 'table_rewrite' event needs to fire at a > time when the code can cope with it. That's the main difficulty in > adding events in that system, asserting their code location safety.
Agreed. > They need to fire before catalogs are modified, or after, not in > between, I agree with that. I don't see other ways of implementing that > than carefully placing the call to user code in the backend's code. Also agreed. > The log insert needs to happen either before or after the rewrite, in > terms of catalog state. I don't see any magic bullet here. And again agreed. I think in this case we need to work out before actually doing anything whether a rewrite will occur, and then remember that decision. If the decision is yes, then we call the trigger. After calling the trigger, we need to revalidate that it hasn't invalidated any critical assumptions upon which we're relying for the sanity of the system (e.g. the table hasn't been altered or dropped). Assuming all is well, we then proceed to do the actual operation, basing the decision as to whether or not to rewrite on the remembered state. I think ALTER TABLE actually has a lot of this machinery already in the form of a distinction between "prep" and "exec". However, there are some cases where the prep work has been folded into the execute phase (or maybe visca versa). So there may be some code cleanup that is needed there, or we may need to move some things from the exec phase to the prep phase to make it all work out. I think it's totally doable, but it's not going to be a 50-line patch. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers