On Thu, Jan 17, 2013 at 5:09 PM, Tom Lane <tgl@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
