On 2014-10-02 17:03:59 -0400, Stephen Frost wrote:
> * Claudio Freire (klaussfreire@gmail.com) wrote:
> > On Thu, Oct 2, 2014 at 4:40 PM, Stephen Frost <sfrost@snowman.net> wrote:
> > > The downside of the 'explain' approach is that the script then has to be
> > > modified to put 'explain' in front of everything and then you have to go
> > > through each statement and consider it. Having a 'dry-run' transaction
> > > type which then produces a report at the end feels like it'd be both
> > > easier to assess the overall implications, and less error-prone as you
> > > don't have to prefex every statement with 'explain'. It might even be
> > > possible to have the local "view" of post-alter statements be available
> > > inside of this 'dry-run' option- that is, if you add a column in the
> > > transaction then the column exists to the following commands, so it
> > > doesn't just error out. Having 'explain <whatever>' wouldn't give you
> > > that and so you really wouldn't be able to have whole scripts run by
> > > just pre-pending each command with 'explain'.
> >
> > That sounds extremely complex. You'd have to implement the fake
> > columns, foreign keys, indexes, etc on most execution nodes, the
> > planner, and even system views.
>
> Eh? We have MVCC catalog access.
So you want to modify the catalog without actually doing the
corresponding actions? That'll be heck of invasive. With changes all
over the backend. We'll need to remove error checks (like for the
existance of relfilenodes), remove rewriting, and such.
Greetings,
Andres Freund
-- Andres Freund http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training &
Services
