Re: DDL Damage Assessment

From: Stephen Frost <sfrost(at)snowman(dot)net>
To: Andres Freund <andres(at)2ndquadrant(dot)com>
Cc: Claudio Freire <klaussfreire(at)gmail(dot)com>, "Joshua D(dot) Drake" <jd(at)commandprompt(dot)com>, Dimitri Fontaine <dimitri(at)2ndquadrant(dot)fr>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: DDL Damage Assessment
Date: 2014-10-02 21:22:06
Message-ID: 20141002212206.GC28859@tamriel.snowman.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

* Andres Freund (andres(at)2ndquadrant(dot)com) wrote:
> On 2014-10-02 17:03:59 -0400, Stephen Frost wrote:
> > > 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.

Yeah, I was getting at it being rather invasive earlier. It really
depends on exactly what we'd support in this mode, which would depend on
just what would be invasive and what wouldn't, I expect. I dislike the
idea of not being able to actually run a real migration script though as
anything else opens the very real possibility that the real script and
the 'explain' script don't do the same thing, making this capability not
nearly as useful..

Thanks,

Stephen

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Bruce Momjian 2014-10-02 21:37:51 Re: INSERT ... ON CONFLICT {UPDATE | IGNORE}
Previous Message Stephen Frost 2014-10-02 21:19:56 Re: DDL Damage Assessment