Re: DDL Damage Assessment

On Thu, Oct 2, 2014 at 5:22 PM, Stephen Frost <sfrost(at)snowman(dot)net> wrote:
> * 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..

I think this is the real issue. Somebody's got to come up with an
infrastructure for reporting locks to be taken without actually
performing the corresponding actions, and it's got to go through
basically the same code paths as it would if we really did it. That's
going to be complicated. But if we make the EXPLAIN code completely
separate from the real code, it will be easy for them to get out of
sync with each other, and then the answers will be wrong.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company