On Thu, Jan 17, 2013 at 5:09 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > Perhaps it would improve matters if we refactored DDL processing so that > there were separate "parse analysis" and "execution" phases, where parse > analysis is (perhaps among other responsibilities) responsible for > identifying and locking all objects to be used in the command. I note > that locking the referenced tables is the responsibility of the parse > analysis step in DML processing, so there's solid precedent for this. > Also, we have some of this approach already for certain commands such > as CREATE TABLE, cf parse_utilcmd.c. > > If we did that, then it'd be feasible to fire event triggers after the > parse analysis step, and the rechecking that Robert describes could be > encapsulated as "redo the parse analysis and see if the result changed". > > It's not clear to me just how this ought to extend to the cascaded-DROP > or inherited-table-ALTER cases, but hey, it's only the beginnings of > an idea.
This is pretty much where I think we should be headed, long term. I believe it would help with the previously-stated desire to have EXPLAIN ALTER TABLE and similar, too. I am not sure it's necessary to go this far to get some of what Dimitri wants, but it may be a necessary prerequisite to getting all of it. -- 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
